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 documentation > that Simon changed in the original commit for that failed feature. > Something might have slipped through the cracks though.
In mvcc.sgml, I see: <varlistentry> <term> <literal>SHARE UPDATE EXCLUSIVE</literal> </term> <listitem> <para> Conflicts with the <literal>SHARE UPDATE EXCLUSIVE</literal>, <literal>SHARE</literal>, <literal>SHARE ROW EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal>, and <literal>ACCESS EXCLUSIVE</literal> lock modes. This mode protects a table against concurrent schema changes and <command>VACUUM</> runs. </para> <para> Acquired by <command>VACUUM</command> (without <option>FULL</option>), <command>ANALYZE</>, <command>CREATE INDEX CONCURRENTLY</>, and --> some forms of <command>ALTER TABLE</command>. </para> </listitem> </varlistentry> and <varlistentry> <term> <literal>ACCESS EXCLUSIVE</literal> </term> <listitem> <para> Conflicts with locks of all modes (<literal>ACCESS SHARE</literal>, <literal>ROW SHARE</literal>, <literal>ROW EXCLUSIVE</literal>, <literal>SHARE UPDATE EXCLUSIVE</literal>, <literal>SHARE</literal>, <literal>SHARE ROW EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal>, and <literal>ACCESS EXCLUSIVE</literal>). This mode guarantees that the holder is the only transaction accessing the table in any way. </para> <para> --> Acquired by the <command>ALTER TABLE</>, <command>DROP TABLE</>, <command>TRUNCATE</command>, <command>REINDEX</command>, <command>CLUSTER</command>, and <command>VACUUM FULL</command> commands. This is also the default lock mode for <command>LOCK TABLE</command> statements that do not specify a mode explicitly. </para> </listitem> </varlistentry> -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers