On Thu, May 3, 2012 at 1:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
There was an attempt to add a transactional advisory lock call type, but my understanding of the plan for that was not to change the existing advisory lock mechanism. It seems that was bungled, so some change is required, but maybe not total revoke. If the change was actually intended that way then I object to it and I also want it changed back. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
