On Wed, Aug 5, 2015 at 11:47 AM, Noah Misch <n...@leadboat.com> wrote: > On Tue, Aug 04, 2015 at 07:35:43AM +0100, Simon Riggs wrote: >> On 4 August 2015 at 05:56, Michael Paquier <michael.paqu...@gmail.com> wrote: >> > 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); > > Agreed; that addresses the foreseeable future of this threat.
Some sub-commands are using ShareRowExclusiveLock... So this one is better :) Assert(locklevel==ShareUpdateExclusiveLock || locklevel >= ShareRowExclusiveLock); Or we simply list all the locks allowed individually... But that's a minor point. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
