Michael Paquier wrote:
> As mentioned in the thread related to lowering locks of autovacuum
> reloptions in ALTER TABLE SET
> (http://www.postgresql.org/message-id/CAFcNs+oX7jVENC_3i54fDQ3ibmOGmknc2tMevdSmvojbSXGbGg@mail.gmail.com),
> I have noticed the following code in
> AlterTableGetLockLevel@tablecmds.c:
> /*
> * Take the greatest lockmode from any subcommand
> */
> if (cmd_lockmode > lockmode)
> lockmode = cmd_lockmode;
>
> The thing is that, as mentioned by Alvaro and Andres on this thread,
> we have no guarantee that the different relation locks compared have a
> monotone hierarchy and we may finish by taking a lock that does not
> behave as you would like to.
Maybe the solution to this is to add the concept of "addition" of two
lock modes, where the result is another lock mode that conflicts with
any lock that would conflict with either of the two operand lock modes.
For instance, if you add a lock mode to itself, you get the same lock
mode; if you "add" anything to AccessExclusive, you get AccessExclusive;
if you "add" anything to AccessShare, you end up with that other lock
mode. The most interesting case in our current lock table is if you
"add" ShareUpdateExclusive to Share, where you end up with
ShareRowExclusive. In essence, holding the result of that operation is
the same as holding both locks, which AFAICS is the behavior we want.
This can be implemented with a simple table and solves the problem for
both ALTER TABLE SET and this existing usage you cite and is not as
invasive as your first proposed solution.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
