Thread: 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