pgsql: Back-patch contrib/vacuumlo's new -l (limit) option into 9.0 and - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Back-patch contrib/vacuumlo's new -l (limit) option into 9.0 and
Date
Msg-id E1SAOyj-0001Ff-4e@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
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 commits b69f2e36402aaa222ed03c1769b3de6d5be5f302 and
64c604898e812aa93c124c666e8709fff1b8dd26, 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

Branch
------
REL9_0_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/3bf25a2a16ca6efefa97f058da062b6c5933ebe1

Modified Files
--------------
contrib/vacuumlo/vacuumlo.c |  145 ++++++++++++++++++++++++++++++++++---------
doc/src/sgml/vacuumlo.sgml  |   24 ++++++--
2 files changed, 135 insertions(+), 34 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Back-patch contrib/vacuumlo's new -l (limit) option into 9.0 and
Next
From: Tom Lane
Date:
Subject: pgsql: Allow new relmapper entries when allow_system_table_mods is true