From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lock levels for ALTER TABLE |
Date: | 2013-01-10 03:17:53 |
Message-ID: | CAB7nPqQpuQA2s-MqZnwacNyQg-DmPOsopErdvA9z0JpsmG4aew@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 10, 2013 at 11:22 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> EnterpriseDB reports that our documentation states that ALTER TABLE
> takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes. However,
> their testing shows only ACCESS EXCLUSIVE locks. Is this accurate?
> Have we changed how ALTER TABLE locks but didn't update our docs?
>
By looking at AlterTableGetLevelLock:tablecmds.c, you are right. All the
ALTER TABLE operations now take an AccessExclusiveLock for all the commands
since 9.1 due to issues with lower level locks involving things like
catalog using SnapshotNow.
Docs should be updated in consequence.
The 9.1-prior locks can be reenabled by using the flag
REDUCED_ALTER_TABLE_LOCK_LEVELS.
Perhaps this could also be specified in the docs.
--
Michael Paquier
http://michael.otacoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-10 03:27:54 | Re: Lock levels for ALTER TABLE |
Previous Message | Noah Misch | 2013-01-10 03:11:36 | Re: lazy_vacuum_heap()'s removal of HEAPTUPLE_DEAD tuples |