Hi!
> The best solution would be to fix the web app but...
...but it's not a problem in my app, but in development
platform (PHP), which is quite buggy.
> Could you set the deadlock_timeout in postgresql.conf?
It is set. Alas, it doesn't help, because there is no
deadlock condition. (Deadlock means two transactions cannot
continue because each tries to set lock conflicting with
already acquired by another, mutually.)
Thank you,
Konstantin Pelepelin
> > 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?