definer function.) Also, heavy concurrent use of row share locks on the
referenced table could pose a performance problem, especially if updates
of it are frequent. Another solution, practical if updates of the
- referenced table are infrequent, is to take an exclusive lock on the
+ referenced table are infrequent, is to take an
+ <literal>ACCESS EXCLUSIVE</literal> lock on the
referenced table when updating it, so that no concurrent transactions
could be examining old row values. Or one could just wait for all
concurrent transactions to end after committing an update of the
<programlisting>
ALTER TABLE tablename ALTER hstorecol TYPE hstore USING hstorecol || '';
</programlisting>
- The <command>ALTER TABLE</command> method requires an exclusive lock on the table,
+ The <command>ALTER TABLE</command> method requires an
+ <literal>ACCESS EXCLUSIVE</literal> lock on the table,
but does not result in bloating the table with old row versions.
</para>
<literal>RowExclusiveLock</literal> when updating the index (including plain
<command>VACUUM</command>). Since these lock types do not conflict, the access
method is responsible for handling any fine-grained locking it might need.
- An exclusive lock on the index as a whole will be taken only during index
- creation, destruction, or <command>REINDEX</command>.
+ An <literal>ACCESS EXCLUSIVE</literal> lock on the index as a whole will be
+ taken only during index creation, destruction, or <command>REINDEX</command>.
</para>
<para>
<command>DELETE</command> will continue to function normally, though you
will not be able to modify the definition of a table with commands such as
<command>ALTER TABLE</command> while it is being vacuumed.)
- <command>VACUUM FULL</command> requires exclusive lock on the table it is
+ <command>VACUUM FULL</command> requires an
+ <literal>ACCESS EXCLUSIVE</literal> lock on the table it is
working on, and therefore cannot be done in parallel with other use
of the table. Generally, therefore,
administrators should strive to use standard <command>VACUUM</command> and
or one of the table-rewriting variants of
<xref linkend="sql-altertable"/>.
These commands rewrite an entire new copy of the table and build
- new indexes for it. All these options require exclusive lock. Note that
+ new indexes for it. All these options require an
+ <literal>ACCESS EXCLUSIVE</literal> lock. Note that
they also temporarily use extra disk space approximately equal to the size
of the table, since the old copies of the table and indexes can't be
released until the new ones are complete.
tables are not dropped or modified in incompatible ways while the
command executes. (For example, <command>TRUNCATE</command> cannot safely be
executed concurrently with other operations on the same table, so it
- obtains an exclusive lock on the table to enforce that.)
+ obtains an <literal>ACCESS EXCLUSIVE</literal> lock on the table to
+ enforce that.)
</para>
<para>
<orderedlist>
<listitem>
<para>
- If the table as a whole is exclusive-locked by someone else,
- <function>pgrowlocks</function> will be blocked.
+ If an <literal>ACCESS EXCLUSIVE</literal> lock is taken on the table,
+ <function>pgrowlocks</function> will be blocked.
</para>
</listitem>
<listitem>
<para>
Drop the index without locking out concurrent selects, inserts, updates,
and deletes on the index's table. A normal <command>DROP INDEX</command>
- acquires an exclusive lock on the table, blocking other accesses until the
- index drop can be completed. With this option, the command instead
- waits until conflicting transactions have completed.
+ acquires an <literal>ACCESS EXCLUSIVE</literal> lock on the table,
+ blocking other accesses until the index drop can be completed. With
+ this option, the command instead waits until conflicting transactions
+ have completed.
</para>
<para>
There are several caveats to be aware of when using this option.
<command>REINDEX</command> is similar to a drop and recreate of the index
in that the index contents are rebuilt from scratch. However, the locking
considerations are rather different. <command>REINDEX</command> locks out writes
- but not reads of the index's parent table. It also takes an exclusive lock
- on the specific index being processed, which will block reads that attempt
- to use that index. In contrast, <command>DROP INDEX</command> momentarily takes
- an exclusive lock on the parent table, blocking both writes and reads. The
- subsequent <command>CREATE INDEX</command> locks out writes but not reads; since
- the index is not there, no read will attempt to use it, meaning that there
- will be no blocking but reads might be forced into expensive sequential
- scans.
+ but not reads of the index's parent table. It also takes an
+ <literal>ACCESS EXCLUSIVE</literal> lock on the specific index being processed,
+ which will block reads that attempt to use that index. In contrast,
+ <command>DROP INDEX</command> momentarily takes an
+ <literal>ACCESS EXCLUSIVE</literal> lock on the parent table, blocking both
+ writes and reads. The subsequent <command>CREATE INDEX</command> locks out
+ writes but not reads; since the index is not there, no read will attempt to
+ use it, meaning that there will be no blocking but reads might be forced
+ into expensive sequential scans.
</para>
<para>
same table. <command>VACUUM FULL</command> rewrites the entire contents
of the table into a new disk file with no extra space, allowing unused
space to be returned to the operating system. This form is much slower and
- requires an exclusive lock on each table while it is being processed.
+ requires an <literal>ACCESS EXCLUSIVE</literal> lock on each table while
+ it is being processed.
</para>
<para>
projects / thirdparty / postgresql.git / commitdiff
