Hi!
> 3. Set the statement_timeout so long-running statements will be
> automatically killed. This can be done on a per-role basis so simply set it
> as desired for the role used by the problematic Java program. It is a
> default and can be changed by the user so if there are individual
> stateme
On 03/20/2012 03:14 AM, Bèrto ëd Sèra wrote:
I currently have an emergency ... As an emergency procedure we have
set a script that each minute has a look at the situation and runs
pg_cancel_backend() against anything that has been waiting for more
than X secs. Then it sleeps one more minute..
Hi,
one thing I was trying to avoid was the connection overhead. For some
reason this box has been configured to 1500 connections (sic), I have no
immediate permission to install a pooler and obviously the overhead in
creating new processes is one of the things that kill it... So I was trying
to m
On 03/20/12 06:14, Bèrto ëd Sèra wrote:
So as a dirty and quick hack to
make sure our failure filter works I wanted to have an external process
kill and relaunch the filter from cron each 30 minutes.
Is there anyway I can mark the process running the filter, maybe using
the update_process_title
Hi all,
running pg 8.3.5 on RHEL (no, they won't upgrade anyway and yes, they know
they should).
I currently have an emergency problem with an external java process that
sends in rubbish, resulting in deadlocks (might simply be "I take forever"
statements that get reported as deadlocks) that do n
