According to
http://archives.postgresql.org/pgsql-general/2012-04/msg00374.php
advisory locks now cause problems for prepared transactions, which
ought to ignore them. It appears to me that this got broken by
commit 62c7bd31c8878dd45c9b9b2429ab7a12103f3590, which marked the
userlock lock method as transactional, which seems just about 100%
misguided to me. At the very least this would require reconsidering
every single place that tests lock transactionality, and that evidently
did not happen.
If this patch weren't already in a released branch I would be arguing
for reverting it. As is, I think we're going to have to clean it up.
I don't have time to look at it in detail right now, though.
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
