Re: Transaction-scope advisory locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Transaction-scope advisory locks
Date
Msg-id 14232.1295537701@sss.pgh.pa.us
Whole thread Raw
In response to Re: Transaction-scope advisory locks  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Responses Re: Transaction-scope advisory locks  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
List pgsql-hackers
Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> writes:
> Another thing I now see is this:

> BEGIN;
> SELECT pg_advisory_xact_lock(1);

> -- do something here

> -- upgrade to session lock
> SELECT pg_advisory_lock(1);
> COMMIT;


> This seems useful, since the xact lock would be automatically released 
> if an error happens during "-- do something here" so you wouldn't need 
> to worry about releasing the lock elsewhere.  But I'm not sure this is 
> safe.  Can anyone see a problem with it?

I think the POLA dictates that the behavior of that should be that you
now have both a transactional and a nontransactional hold on the lock;
and only the transactional hold goes away at commit.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: pg_dump directory archive format / parallel pg_dump
Next
From: Bruce Momjian
Date:
Subject: Re: pg_basebackup for streaming base backups