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_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers