From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 16:30:01 |
Message-ID: | 26668.1336062601@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Thu, May 3, 2012 at 11:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm inclined to think that a saner implementation would involve
>> splitting the userlock lockmethod into two, one transactional and one
>> not.
> hm, would that be exposed through the pg_locks view? some users might
> be running queries like "select * from pg_locks where
> locktype='advisory' and ..."
I don't think we can or should change what pg_locks reports. So they'd
have to look like just one lockmethod at that level.
I'm not actually sure that a split is a practical idea anyway, given
that assorted places use a LockMethod as an identifier for a class of
locks; unless all of those happen to want to distinguish transactional
and session-level userlocks, it'd be problematic. I plan to look also
at the idea of removing the "transactional" field and seeing what that
breaks...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-05-03 16:37:54 | CLOG extension |
Previous Message | Tom Lane | 2012-05-03 16:25:41 | Re: Advisory locks seem rather broken |