From: | mike g <mike(at)thegodshalls(dot)com> |
---|---|
To: | Konstantin Pelepelin <checat(at)pochtamt(dot)ru> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: are there ways for 'idle timeout'? |
Date: | 2004-07-10 03:29:11 |
Message-ID: | 1089430151.10763.17.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
The best solution would be to fix the web app but....
Could you set the deadlock_timeout in postgresql.conf? According to
documentation that will kill one of the transactions that has issued the
lock on the table or row?
On Fri, 2004-07-09 at 09:36, Konstantin Pelepelin wrote:
> Hi!
>
> In situations where client application is unstable there is very big
> chance that it will enter transaction, acquire very restrictive locks and
> then hang. This means: connection is not lost, but nothing happens and any
> transaction in conflict with those locks will hang too.
> statement_timeout can help to detect this situation, but not to solve,
> when most of applications fail. Currently the only way I see to solve is
> to kill locked postgres backend, or (more difficult) find hanging client
> among hundreds of similar.
> I work with web-application (Apache-mod_php-Postgres), where PHP hangs
> every 100000 requests or so, which means from a day to some weeks between
> whole system hangs.
> I could set up a cron job which will kill every postgres backend "idle in
> transaction" which was started more than 10 minutes ago, but I can have
> accident problems with some long-running tasks.
> The best solution I see is having an (per session)
> idle_transaction_timeout or idle_connection_timeout setting.
> But there is no such thing in postgres!
> Scanning through list I've not found any workaround.
> Looking into TODO I don't see any plans for it.
> Is it too difficult implementing or I've missed something or are there
> workarounds?
>
> Hoping on your responce,
> Konstantin Pelepelin
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-10 04:25:01 | Re: Forcing postgres to reload current time zone. |
Previous Message | mike g | 2004-07-10 03:15:41 | Re: Bad dumps... |