When creating an index concurrently in Postgres, how do you make the statement run in the background? Once I run the query in psql, the statement does not return and I'm not able to quit the process and disconnect SSH to server.
Edit: I understand we could use something like tmux to keep the shell alive in the background. But I'm trying to understand if Postgres' CONCURRENT index operation does not return immediately.
Yes, although the index is created concurrently, the DDL itself will not return immediately.
Ref: https://gist.github.com/bryanrite/36714b13e0aece2f6c43#safe
Add an index concurrently (Example), Note: it will still take a long time to run the migration, but it won't write-lock the table.
Use screen in linux,
screen -S session_name
then execute the command in psql.
You can detach from the screen session at any time by typing:
Ctrl+a d
To resume your session use
screen -r
Read this for more info
This way you can let your process run in the background even though you disconnect your session.
Related
when I am trying to execute below query through Perl script my code is getting unresponsive (not throwing any error only cursor is waiting to execute this query).
ALTER TABLE base_table
DETACH PARTITION part_table;
interestingly above query is working fine on the postgres terminal.
what are all the possible scenarios for which i am facing this issue and how it could be resolved?
There is a concurrent long running transaction holding a lock on the table. Terminate all such transactions, and it will work fine.
I have executed a plv8 function on pgadmin 4, that uses nested for loops and some array functions.
This query was stopped using pgadmin cancel query (stop) button in GUI.
24 hours later, This query still shows up as active and running.
I have Tried, pg_cancel_backend and pg_terminate_backend, but seems to have no impact.
Tried pg_ctl kill (TERM/ABRT/INT)command, but pid is not found.
However, AWS performance insights dashboard shows up, the query using 25-30% of CPU.
If you guys could suggest alternate ways, to terminate this query, That'd be really helpful.
Thanks.
I am not very familiar with databases or SQL and wanted to make sure that I don't mess anything up. I did:
SELECT pid, state, usename, query FROM pg_stat_activity;
To check if I had any queries and there were several that had the state active. Do I just cancel them by doing:
select pg_cancel_backend(PID);
And this won't affect anything except the my queries, correct? I also wanted to figure out why those queries were still in the state active. I have a python file where I read in my sql file, but I stopped running the python file in the middle of reading my sql file. Is that possibly why it happened and why the states are still active?
Yes, this is what pg_cancel_backend(pid) is for. Why exactly the query is still running depends on a few things - could be waiting to grab a lock, or the query could just take a long time - but given the python processes that started the queries have exited, the connection is technically already closed, the PG backend process just hasn't noticed yet. It won't notice until the query completes and it tries to return the query status to the client, at which point it'll rollback the transaction when it sees the connection is no longer present.
The only effect pg_cancel_backend on the PIDs of those backends should have is to cause PG to notice the connection is closed immediately, rather than whenever the query completes.
I have been trying to truncate a table using SQlWorkbench. Suddenly, SqlWorkbench got freezed, while the truncate was in progress. I had to kill workbench from taskmanager. But now none of the queries are working on the table on which the truncate was aborted abruptly. For other tables queries are working fine. Need help, as I have to upload fresh data on the same table. Currently I am not even able to drop the table. What can be done to resolve this issue?
This looks like the TRUNCATE got stuck behind a lock, and then you killed the front end, while TRUNCATE kept running.
Connect to the database as superuser and examine the pg_stat_activity view; you should see some long running transactions.
Use the function pg_terminate_backend to kill these sessions by their pid.
I want to do some basic experiment on PostgreSQL, for example to generate deadlocks, to create non-repeatable reads, etc. But I could not figure out how to run multiple transactions at once to see such behavior.
Can anyone give me some Idea?
Open more than one psql session, one terminal per session.
If you're on Windows you can do that by launching psql via the Start menu multiple times. On other platforms open a couple of new terminals or terminal tabs and start psql in each.
I routinely do this when I'm examining locking and concurrency issues, used in answers like:
https://stackoverflow.com/a/12456645/398670
https://stackoverflow.com/a/12831041/398670
... probably more. A useful trick when you want to set up a race condition is to open a third psql session and BEGIN; LOCK TABLE the_table_to_race_on;. Then run statements in your other sessions; they'll block on the lock. ROLLBACK the transaction holding the table lock and the other sessions will race. It's not perfect, since it doesn't simulate offset-start-time concurrency, but it's still very helpful.
Other alternatives are outlined in this later answer on a similar topic.
pgbench is probably the best solution in yours case. It allows you to test different complex database resource contentions, deadlocks, multi-client, multi-threaded access.
To get dealocks you can simply right some script like this ('bench_script.sql):
DECLARE cnt integer DEFAULT 0;
BEGIN;
LOCK TABLE schm.tbl IN SHARE MODE;
select count(*) from schm.tabl into cnt;
insert into schm.tbl values (1 + 9999*random(), 'test descr' );
END;
and pass it to pgbench with -f parameter.
For more detailed pgbench usage I would recommend to read the official manual for postgreSQL pgBench
and get acquented with my pgbench question resolved recently here.
Craig Ringer provide a way that open mutiple transactions manualy， if you find that is not very convenient， You can use pgbench run multiple transactions at once.