mirror of
https://github.com/postgres/postgres.git
synced 2025-07-21 16:02:15 +03:00
Back-patch contrib/vacuumlo's new -l (limit) option into 9.0 and 9.1.
Since 9.0, removing lots of large objects in a single transaction risks exceeding max_locks_per_transaction, because we merged large object removal into the generic object-drop mechanism, which takes out an exclusive lock on each object to be dropped. This creates a hazard for contrib/vacuumlo, which has historically tried to drop all unreferenced large objects in one transaction. There doesn't seem to be any correctness requirement to do it that way, though; we only need to drop enough large objects per transaction to amortize the commit costs. To prevent a regression from pre-9.0 releases wherein vacuumlo worked just fine, back-patch commitsb69f2e3640
and64c604898e
, which break vacuumlo's deletions into multiple transactions with a user-controllable upper limit on the number of objects dropped per transaction. Tim Lewis, Robert Haas, Tom Lane
This commit is contained in:
@ -49,6 +49,19 @@ vacuumlo [options] database [database2 ... databaseN]
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-l</option> <replaceable>limit</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Remove no more than <replaceable>limit</> large objects per
|
||||
transaction (default 1000). Since the server acquires a lock per LO
|
||||
removed, removing too many LOs in one transaction risks exceeding
|
||||
<xref linkend="guc-max-locks-per-transaction">. Set the limit to
|
||||
zero if you want all removals done in a single transaction.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-U</option> <replaceable>username</></term>
|
||||
<listitem>
|
||||
@ -75,7 +88,7 @@ vacuumlo [options] database [database2 ... databaseN]
|
||||
<listitem>
|
||||
<para>
|
||||
Force <application>vacuumlo</application> to prompt for a
|
||||
password before connecting to a database.
|
||||
password before connecting to a database.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -110,18 +123,19 @@ vacuumlo [options] database [database2 ... databaseN]
|
||||
<title>Method</title>
|
||||
|
||||
<para>
|
||||
First, it builds a temporary table which contains all of the OIDs of the
|
||||
large objects in that database.
|
||||
First, <application>vacuumlo</> builds a temporary table which contains all
|
||||
of the OIDs of the large objects in the selected database.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
It then scans through all columns in the database that are of type
|
||||
<type>oid</> or <type>lo</>, and removes matching entries from the
|
||||
temporary table.
|
||||
temporary table. (Note: only types with these names are considered;
|
||||
in particular, domains over them are not considered.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remaining entries in the temp table identify orphaned LOs.
|
||||
The remaining entries in the temporary table identify orphaned LOs.
|
||||
These are removed.
|
||||
</para>
|
||||
</sect2>
|
||||
|
Reference in New Issue
Block a user