Re: Forcibly vacating locks

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Laurent Birtz <laurent(dot)birtz(at)kryptiva(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Forcibly vacating locks
Date: 2008-06-19 02:43:23
Message-ID: 200806190243.m5J2hNp27050@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Laurent Birtz wrote:
> Hello,
>
> I am using Postgres in a high-availability environment and I'd like to
> know whether Postgres has provisions to kick off a misbehaving client
> that has obtained an advisory lock on the database and won't release it
> in a timely fashion. I am not worried about malicious clients, however I
> am concerned that a client may hang for a very long time in the middle of
> a transaction due to a programming error, an overloaded machine or
> another bizarre set of circumstances. TCP keepalive packets can improve
> the situation, but they won't prevent some problems from occurring.
>
> For this reason, it is the policy of my company to avoid using explicit
> locks in Postgres altogether. However, as you can imagine, it is hard at
> times to avoid race conditions with this programming model.
>
> Thus, I'd like Postgres to offer a function like set_watchdog(int nb_ms).
> I would call set_watchdog(10000) to enable the watchdog just before I
> obtained the lock, then I would call set_watchdog(0) to disable the
> watchdog after I released the lock. If a client froze, the watchdog would
> eventually trigger and drop the connection to the client, thereby
> preventing the whole system from freezing.
>
> I have three specific questions:
>
> 1) Does Postgres offer something like this already? I'm aware of
> statement_timeout, but it doesn't do exactly what I need. A possible
> kludge would be to parse the 'pg_locks' table and kill the offending
> Postgres backend, but I'd rather avoid doing this.

No. The closest thing we have is log_lock_waits in 8.3. I wonder if
you could hack up something to monitor the server logs for such messages
and cancel the queries.

> 2) Is there any hostility about the notion of implementing this feature
> into Postgres?

Probabably --- it seems like a narrow use case.

> 3) Would it be hard to implement it? After a brief code review, I think
> it would make sense to reuse the SIGALARM signal used by
> statement_timeout to forcibly close the Postgres connection when
> the watchdog triggers.

Not too hard.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Artacus 2008-06-19 03:11:10 Problem with volatile function
Previous Message Douglas McNaught 2008-06-19 02:36:28 Re: HA best pratices with postgreSQL