Skip site navigation (1) Skip section navigation (2)

Re: Advisory locks seem rather broken

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Subject: Re: Advisory locks seem rather broken
Date: 2012-05-03 08:43:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, May 3, 2012 at 1:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> According to
> 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         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Jan UrbańskiDate: 2012-05-03 09:04:38
Subject: Re: PL/Python result set slicing broken in Python 3
Previous:From: Heikki LinnakangasDate: 2012-05-03 06:14:04
Subject: Re: Latch for the WAL writer - further reducing idle wake-ups.

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group