Re: tablecmds.c and lock hierarchy
От | Simon Riggs |
---|---|
Тема | Re: tablecmds.c and lock hierarchy |
Дата | |
Msg-id | CANP8+jKn9GY1KiA=MG1CARHcD9iFcagOcmfmVD7RNpZBgjFjVw@mail.gmail.com обсуждение исходный текст |
Ответ на | tablecmds.c and lock hierarchy (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: tablecmds.c and lock hierarchy
Re: tablecmds.c and lock hierarchy |
Список | pgsql-hackers |
On 4 August 2015 at 05:56, Michael Paquier <michael.paquier@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_3i54fDQ3ibmOGmknc2tMevdSmvojbSXGbGg@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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: