Re: tablecmds.c and lock hierarchy
От | Michael Paquier |
---|---|
Тема | Re: tablecmds.c and lock hierarchy |
Дата | |
Msg-id | CAB7nPqTYUYwY00XOrH5r+ingC6dBkGt3-DLz5N3KqDJVbtOZGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: tablecmds.c and lock hierarchy (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: tablecmds.c and lock hierarchy
|
Список | pgsql-hackers |
On Tue, Aug 4, 2015 at 3:35 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > 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 Thread: http://www.postgresql.org/message-id/CAFcNs+oX7jVENC_3i54fDQ3ibmOGmknc2tMevdSmvojbSXGbGg@mail.gmail.com Particularly those messages: http://www.postgresql.org/message-id/20150731022857.GC11473@alap3.anarazel.de http://www.postgresql.org/message-id/20150731200012.GC2441@postgresql.org http://www.postgresql.org/message-id/CAB7nPqSK-hSZG7T1tAJ_=HEYsi6P1ejgX2x5LW3LYXJ7=9cOiQ@mail.gmail.com > Assert(locklevel==ShareUpdateExclusiveLock || > locklevel>ShareRowExclusiveLock); Yep, true as things stand now. But this would get broken if we add a new lock level between ShareRowExclusiveLock and AccessExclusiveLock that does not respect the current monotone hierarchy between those. -- Michael
В списке pgsql-hackers по дате отправления: