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

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(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Chris Hoover
Sent: 10 May 2006 12:30 am
To: pgsql-admin(at)postgresql(dot)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

tough luck .. could u query the unix groups and see if u could retrive the
original filenames and directory structure ?.

On 5/29/06, Daniel Drotos <drdani(at)mazsola(dot)iit(dot)uni-miskolc(dot)hu> wrote:
>
> 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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Best,
Gourish Singbal

Daniel Drotos <drdani(at)mazsola(dot)iit(dot)uni-miskolc(dot)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