On 4 August 2015 at 05:56, Michael Paquier <michael.paqu...@gmail.com> wrote:
> Hi all, > > 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. We are now lucky enough that ALTER TABLE > only uses ShareUpdateExclusiveLock, ShareRowExclusiveLock and > AccessExclusiveLock that actually have a hierarchy so this is not a > problem yet. > However it may become a problem if we add in the future more lock > modes and that are used by ALTER TABLE. > Please provide the link to the discussion of this. I don't see a problem here right now that can't be solved by saying Assert(locklevel==ShareUpdateExclusiveLock || locklevel>ShareRowExclusiveLock); -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
