Marko Tiikkaja <marko.tiikk...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers