On Wed, Aug 5, 2015 at 3:05 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Aug 4, 2015 at 2:41 AM, Michael Paquier > <michael.paqu...@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
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index 970abd4..3aff387 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -3057,8 +3057,13 @@ AlterTableGetLockLevel(List *cmds) } /* - * Take the greatest lockmode from any subcommand + * Take the greatest lockmode from any subcommand following a monotone + * hierarchy. */ + Assert(cmd_lockmode == ShareUpdateExclusiveLock || + cmd_lockmode == ShareRowExclusiveLock || + cmd_lockmode == ExclusiveLock || + cmd_lockmode == AccessExclusiveLock); if (cmd_lockmode > lockmode) lockmode = cmd_lockmode; }
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
