Re: tablecmds.c and lock hierarchy
От | Noah Misch |
---|---|
Тема | Re: tablecmds.c and lock hierarchy |
Дата | |
Msg-id | 20150805024738.GA1768550@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: tablecmds.c and lock hierarchy (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: tablecmds.c and lock hierarchy
|
Список | pgsql-hackers |
On Tue, Aug 04, 2015 at 07:35:43AM +0100, Simon Riggs wrote: > On 4 August 2015 at 05:56, Michael Paquier <michael.paquier@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.
В списке pgsql-hackers по дате отправления: