From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Michal Taborsky - Internet Mall <michal(dot)taborsky(at)mall(dot)cz> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: LOCK ... NOWAIT throws error |
Date: | 2006-11-29 18:09:01 |
Message-ID: | 1164823741.7773.119.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2006-11-29 at 16:47 +0100, Michal Taborsky - Internet Mall
wrote:
> Hello.
>
> We started using, in one of our applications, the LOCK ... NOWAIT
> functionality. It works as it's supposed to, but there is one, albeit
> tiny, annoyance about it.
>
> When the LOCK cannot be immediately obtained, this statement logs an
> ERROR message. But in this case, I think it is not appropriate to call
> this event an error, since I am well aware it might happen and actually
> expect it, since I use the NOWAIT switch.
>
I think it must be an error if it's uncaught. Otherwise how would it
inform the client application that no lock was acquired?
The best thing to do is create a procedural language function that
catches the error. Then, it will not be reported. For example:
CREATE OR REPLACE FUNCTION lock_nowait_noerror() RETURNS BOOLEAN
LANGUAGE plpgsql AS
$$
BEGIN
BEGIN
LOCK locktable NOWAIT;
RETURN TRUE;
EXCEPTION WHEN lock_not_available THEN
RETURN FALSE;
END;
END;
$$;
Then, in your client app you can check the return value to see whether
the lock was acquired.
Hope this helps,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Ritesh Nadhani | 2006-11-29 18:15:01 | Re: Development of cross-platform GUI for Open Source DBs |
Previous Message | Joshua D. Drake | 2006-11-29 17:40:01 | Re: Only MONO/WinForms is a way to go |