Re: tablecmds.c and lock hierarchy

On Wed, Aug 5, 2015 at 3:05 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 4, 2015 at 2:41 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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