Thread: Terminating Idle Connections
If this is not possible, would there be a possibility of it being added to a future version?
thanks,
Chris
RH 4.0 AS
PostgreSQL 8.1.3
Chris,
In a shell script, you could do a “ps auxwww|grep ‘idle in transaction’” which would give you a list of all processes with a status of “idle in transaction.” Then run through each line of the output, use “awk” to find the process id, and issue a “kill <pid>” to each process.
Obviously this kills all idle in transaction processes, of which some may be genuinely waiting.
The best idea would be to see where your idle transactions are coming from, and work out why they’re being left idle and not disconnecting (ie. In your app/s.) Better to find the cause of the problem than try and patch it.
A “ps auxwww|grep postgres” will show you the host of the connection, the DB it’s connect to and the user (as long as this is enabled in your PG config.)
Andy
From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Chris Hoover
Sent: 10 May 2006 12:30 am
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Terminating Idle Connections
Is there a way inside of Postgresql to automatically terminate idle connections? I would like to terminate any connection to my database that has not has any activity for a specified period of time. I would like to be able to do this despite the state of the connection (the majority of my truly idle connections show "idle in transaction" in the process table). I would love for the db engine to do this, but if it can't, is there an easy way to do this outside the database with some sort of script?
If this is not possible, would there be a possibility of it being added to a future version?
thanks,
Chris
RH 4.0 AS
PostgreSQL 8.1.3 !DSPAM:14,4461265534491787116627!
"idle in transaction" usually means the software using the database has a bug. Technically it means your software issues a "BEGIN" statement, but never a rollback or commit. PostgreSQL doesn't provide a way to kill processes that are blocked due to programming errors, that would kind of defeat the purpose. Try to find out what exactly causes this. It's definitely a transaction that was started but never ended. Maybe turning on SQL statement logging in postgresql.conf can help to find the culprit. On Tuesday 09 May 2006 16:29, Chris Hoover wrote: > Is there a way inside of Postgresql to automatically terminate idle > connections? I would like to terminate any connection to my database that > has not has any activity for a specified period of time. I would like to > be able to do this despite the state of the connection (the majority of my > truly idle connections show "idle in transaction" in the process table). I > would love for the db engine to do this, but if it can't, is there an easy > way to do this outside the database with some sort of script? > > If this is not possible, would there be a possibility of it being added to > a future version? > > thanks, > > Chris > > RH 4.0 AS > PostgreSQL 8.1.3 -- Open Source Solutions 4U, LLC 1618 Kelly St Phone: +1 707 568 3056 Santa Rosa, CA 95401 Cell: +1 650 302 2405 United States Fax: +1 707 568 6416
Hi, During machine maintenance I've made 'rm -rf *' on postgres data directory by a (very stupid) mistake. Postmaster was not running that time. Using e2undel I dumped out contents of deleted files (3728 files have been deleted by that command). Because of "rm -r", sizes of recovered directory files are 0, so I have no filenames and directory structure. Is there any chance of recover data directory if only dumped file contents are available? Daniel
Hi,
During machine maintenance I've made 'rm -rf *' on postgres data
directory by a (very stupid) mistake. Postmaster was not running that
time.
Using e2undel I dumped out contents of deleted files (3728 files have
been deleted by that command). Because of "rm -r", sizes of recovered
directory files are 0, so I have no filenames and directory structure.
Is there any chance of recover data directory if only dumped file
contents are available?
Daniel
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Best,
Gourish Singbal
Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu> writes:
> During machine maintenance I've made 'rm -rf *' on postgres data
> directory by a (very stupid) mistake. Postmaster was not running that
> time.
> Using e2undel I dumped out contents of deleted files (3728 files have
> been deleted by that command). Because of "rm -r", sizes of recovered
> directory files are 0, so I have no filenames and directory structure.
> Is there any chance of recover data directory if only dumped file
> contents are available?
If you could identify which file is which, you could manually
reconstruct the directories, but I'm afraid the odds of doing that
correctly with so many files are nil. Time to get out your last
backup.
regards, tom lane
On Mon, 29 May 2006, Tom Lane wrote: > If you could identify which file is which, you could manually > reconstruct the directories, but I'm afraid the odds of doing that Postgresql data files do not identifying themselves (in their content) so it's an ext2fs problem. I'm trying to solve it, just for fun, and to get experience how can it be done. Daniel
Daniel Drotos wrote: > On Mon, 29 May 2006, Tom Lane wrote: > > >If you could identify which file is which, you could manually > >reconstruct the directories, but I'm afraid the odds of doing that > > Postgresql data files do not identifying themselves (in their content) > so it's an ext2fs problem. I'm trying to solve it, just for fun, and > to get experience how can it be done. You could guess what some files are, particularly the system catalogs, by searching for known contents (for example, if you see the string "pg_class" and "pg_attribute" you could think it's the file for pg_class itself). You could identify several system catalogs easily this way. But for user tables it would be quite complicated. I'd use the number of atts as a first clue (assuming you have already restored the system catalogs). I don't know how you intend to guess at telling the pg_clog files apart though :-) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support