Re: tablecmds.c and lock hierarchy - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: tablecmds.c and lock hierarchy
Date
Msg-id CAB7nPqTtP8dNhcHtfY+d23GNgV-X7eg7=XcgZVRU4iQA0cRKjQ@mail.gmail.com
Whole thread Raw
In response to Re: tablecmds.c and lock hierarchy  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Aug 5, 2015 at 3:05 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Aug 4, 2015 at 2:41 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> Yep, true as things stand now. But this would get broken if we add a
>> new lock level between ShareRowExclusiveLock and AccessExclusiveLock
>> that does not respect the current monotone hierarchy between those.
>
> But we're probably not going to do that, so it doesn't matter; and if
> we do do it, we can worry about it then.  I don't think this is worth
> getting concerned about now.

OK. Then let me suggest the attached Assert safeguard then. It ensures
that all the locks used follow a monotony hierarchy per definition of
what is on the conflict table. That looks like a cheap insurance...

In any case, this means as well that we should move on with the
current logic presented by Fabrizio on the other thread.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: David Rowley
Date:
Subject: Re: WIP: Make timestamptz_out less slow.