Thread: Terminating Idle Connections

Terminating Idle Connections

From
"Chris Hoover"
Date:
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

Re: Terminating Idle Connections

From
"Andy Shellam"
Date:

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!

Re: Terminating Idle Connections

From
"Uwe C. Schroeder"
Date:
"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

recover of data directory

From
Daniel Drotos
Date:
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

Re: recover of data directory

From
"Gourish Singbal"
Date:
 
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@mazsola.iit.uni-miskolc.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@postgresql.org so that your
      message can get through to the mailing list cleanly



--
Best,
Gourish Singbal

Re: recover of data directory

From
Tom Lane
Date:
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

Re: recover of data directory

From
Daniel Drotos
Date:
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

Re: recover of data directory

From
Alvaro Herrera
Date:
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