I am trying to terminate a session (a specific session or all sessions, doesnt matter) in postgresql 8.3 and am having trouble doing that. I know in newer versions (8.4 and later) there is a pg_terminate_backend command that will do the trick but this is not available in postgresql 8.3. If I use pg_stat_activity, I can see all the sessions that are active but have no way of terminating them.
The solution does not have to necessarily be sql commands but I would like it to be independent of the OS that is being used (i.e. no DOS/UNIX commands).
Stopping and starting the postgres service in windows services works perfectly but this is an OS specific approach. Using 'pg_ctl restart -D DATA_DIR' does not stop the service however. Actually using pg_ctl to try and restart the service at the time I am trying to do it causes some weird behavior. If there is a way I can somehow use pg_ctl to force shutdown the process like I assume windows does, then I can probably use that.
Anyways, I am looking for a way to terminate one or all sessions in postgresql 8.3 that is not platform specific. Any help would be great!
You can use pg_cancel_backend():
select pg_cancel_backend(55555);
You can use this with pg_stat_activity. For example:
select pg_cancel_backend(procpid)
from pg_stat_activity where current_query='<IDLE>';
If that doesn't work you can try this:
pg_ctl kill -TERM pid
That should be OS independent. I'm not sure if there's any real difference in behaviour.
Other than that you could try stopping and starting the server, but you indicated odd behaviour from that. (What kind?)
Finally, for an OS specific option, on linux you can of course try using the kill command. kill -15 (SIGTERM) is safe; that's basically what pg_terminate_backend uses: kill -15 <pid>. kill -9 is moderately unsafe and you should use it only as a last resort.
su - posgres
psql
SELECT pg_terminate_backend(pg_stat_activity.procpid) FROM pg_stat_activity WHERE procpid <> pg_backend_pid() AND datname = 'dbname' ;
drop database "database name";
Related
I'm having a remote machine that's using postgresql 9.2.1. Suddenly, i couldn't start my pgsql server(pg_isready command is rejecting connections). what my doubt is that, is there any possibility that i can start my database in Standalone back end mode, while it is not opening in Normal user mode?
And, what is the difference in starting the pgsql server in those two modes?
Thanks in advance.
Rather than using single user mode, look into the PostgreSQL server log file. That should tell you what the problem is.
In single-user mode, there will be just a single process accessing the database; none of the background processes are started. You'll be superuser, and the database process will last only for the duration of your session. This is something for emergency recovery, like when system tables are corrupted, you forgot your superuser password and so on.
In your case, single-user mode will probably only help if the database shut down because of an impending transaction ID wraparound. You can then issue the saving VACUUM (FREEZE) in single-user mode.
As soon as you have fixed your problem, upgrade to a supported release of PostgreSQL.
I'm on RHEL6 and have installed PostgreSQL. Now whenever I want to start development I need to run the following command to start PostgreSQL
/opt/PostgreSQL/9.5/bin/postgres -D /opt/PostgreSQL/9.5/data
Then it halts for that terminal and I need to start another session of postgresql into another terminal. Whats wrong in Installation? and How to rectify this problem?
Image of practical for better understanding
https://www.postgresql.org/docs/current/static/app-postgres.html
The utility command pg_ctl can be used to start and shut down the
postgres server safely and comfortably.
If at all possible, do not use SIGKILL to kill the main postgres
server. Doing so will prevent postgres from freeing the system
resources (e.g., shared memory and semaphores) that it holds before
terminating. This might cause problems for starting a fresh postgres
run.
use pg_ctl -D /opt/PostgreSQL/9.5/data start instead, otherwise one day your database will tell you about corrupted data
Assuming I started execution of an inefficient and long-running query in an IBM DB2 database using the CLP. Maybe there are some terrible joins in there that take a lot of processing time in the database. Maybe I don't have the much needed index yet.
# db2 +c -m
db2 => connect to mydb
db2 => select * from view_with_inefficient_long_running_query
//// CLP waiting for database response
How do I cancel the processing of this statement/query without killing DB2 CLP? I can do so by killing it, that is, by pressing Ctrl-C:
db2 => select * from view_with_inefficient_long_running_query
^C
SQL0952N Processing was cancelled due to an interrupt. SQLSTATE=57014
# db2 +c -m
db2 =>
But is there another more elegant way? Perhaps another Ctrl- shortcut? I already saw this question, but it doesn't talk about what I want.
AFAIK, there is not CTRL- to terminate CLP. Your option is to open another terminal session and use the LIST/FORCE applications, CTRL-Z the CLP to suspend it and use another CLP to LIST/FORCE or use a GUI tool like Data Server Manager to find the application and force it to terminate.
db2 list applications for <database>
get the application handle for the session(s) you want to terminate.
db2 force application ( application-handle )
see LIST APPLICATIONS and FORCE APPLICATION.
Would you rather use a QueryTimeout configuration as in https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.apdv.cli.doc/doc/r0008809.html
This way your command would stop and report SQLSTATE 57013
-913 UNSUCCESSFUL EXECUTION CAUSED BY DEADLOCK OR TIMEOUT.
Rather than use CLP directly, why not go directly from the UNIX prompt?
db2 "select * from view_with_inefficient_long_running_query"
You can hit Ctrl-C to cancel your query. The connection to the database is maintained by the DB2 Backend Process (db2bp), and you get all of the benefits of working in a UNIX shell – superior history, command pipelines, etc.
I have dozens of unlogged tables, and doc says that an unlogged table is automatically truncated after a crash or unclean shutdown.
Based on that, I need to check some tables after database starts to see if they are "empty" and do something about it.
So in short words, I need to execute a procedure, right after database is started.
How the best way to do it?
PS: I'm running Postgres 9.1 on Ubuntu 12.04 server.
There is no such feature available (at time of writing, latest version was PostgreSQL 9.2). Your only options are:
Start a script from the PostgreSQL init script that polls the database and when the DB is ready locks the tables and populates them;
Modify the startup script to use pg_ctl start -w and invoke your script as soon as pg_ctl returns; this has the same race condition but avoids the need to poll.
Teach your application to run a test whenever it opens a new pooled connection to detect this condition, lock the tables, and populate them; or
Don't use unlogged tables for this task if your application can't cope with them being empty when it opens a new connection
There's been discussion of connect-time hooks on pgsql-hackers but no viable implementation has been posted and merged.
It's possible you could do something like this with PostgreSQL bgworkers, but it'd be a LOT harder than simply polling the DB from a script.
Postgres now has pg_isready for determining if the database is ready.
https://www.postgresql.org/docs/11/app-pg-isready.html
Is there a way to force clients to disconnect from PostgreSQL? I'm looking for the equivlent of DB2's force application all.
I'd like to do this on my development box because when I've got database consoles open, I can't load a database dump. I have to quit them first.
Kills idle processes in PostgreSQL 8.4:
SELECT procpid, (SELECT pg_terminate_backend(procpid)) as killed from pg_stat_activity
WHERE current_query LIKE '<IDLE>';
Combine pg_terminate_backend function and the pg_stat_activity system view.
This SO answer beautifully explains (full quote from araqnid between the horizontal rules, then me again):
To mark database 'applogs' as not accepting new connections:
update pg_database set datallowconn = false where datname = 'applogs';
Another possibility would be to revoke 'connect' access on the database for the client role(s).
Disconnect users from database = kill backend. So to disconnect all other users from "applogs" database, for example:
select pg_terminate_backend(procpid)
from pg_stat_activity
where datname = 'applogs' and procpid <> pg_backend_pid();
Once you've done both of those, you are the only user connected to 'applogs'. Although there might actually be a delay before the backends actually finish disconnecting?
Update from MarkJL: There is indeed a delay before the backends finish disconnecting.
Now me again: That being said, mind that the procpid column was renamed to pid in PostgreSQL 9.2 and later.
I think that this is much more helpful than the answer by Milen A. Radev which, while technically the same, does not come with usage examples and real-life suggestions.
I post my answer because I couldn't use any of them in my script, server 9.3:
psql -U postgres -c "SELECT pid, (SELECT pg_terminate_backend(pid)) as killed from pg_stat_activity WHERE datname = 'my_database_to_alter';"
In the next line, you can do anything yo want with 'my_database_to_alter'. As you can see, yo perform the query from the "postgres" database, which exists almost in every postgresql installation.
Doing by superuser and outside the problem-database itself worked perfect for me.
probably a more heavy handed approach then should be used but:
for x in `ps -eF | grep -E "postgres.*idle"| awk '{print $2}'`;do kill $x; done
I found this thread on the mailing list. It suggests using SIGTERM to cause the clients to disconnect.
Not as clean as db2 force application all.