LOCK ... NOWAIT throws error
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.
Why is it an annoyance? We monitor the logs for ERROR messages and act
upon them, but in this case we have to filter it out or ignore it.
I wonder, if there isn't a possibility to change this reporting behavior
(well, probably no, but I am asking just in case). Or if no, you might
take it as a suggestion for next release.
Bye.
--
Michal T�borsk�
chief systems architect
Internet Mall, a.s.
<http://www.MALL.cz>
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