Обсуждение: 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

"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

--
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