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?
--
Bruce Momjian
On Thu, Jan 10, 2013 at 11:22 AM, Bruce Momjian br...@momjian.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
Bruce Momjian br...@momjian.us writes:
EnterpriseDB reports that our documentation states that ALTER TABLE
takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
Where do they see that? We certainly reverted all of the documentation
that Simon changed in the original commit for that
On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
EnterpriseDB reports that our documentation states that ALTER TABLE
takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
Where do they see that? We certainly reverted all of the
Bruce Momjian br...@momjian.us writes:
On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
EnterpriseDB reports that our documentation states that ALTER TABLE
takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
Where do they see that?
I wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
Something might have slipped through the cracks though.
In mvcc.sgml, I see:
-- some forms of commandALTER TABLE/command.
A bit of git blame later, the culprit is commit
