From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Back-patch contrib/vacuumlo's new -l (limit) option into 9.0 and |
Date: | 2012-03-21 17:05:41 |
Message-ID: | E1SAOyj-0001Fd-4i@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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_1_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/5bd06e619c82c3b2e29fed40aae5fc39a9620908
Modified Files
--------------
contrib/vacuumlo/vacuumlo.c | 143 ++++++++++++++++++++++++++++++++++--------
doc/src/sgml/vacuumlo.sgml | 22 ++++++-
2 files changed, 133 insertions(+), 32 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-03-21 18:09:54 | pgsql: Allow new relmapper entries when allow_system_table_mods is true |
Previous Message | Robert Haas | 2012-03-21 16:40:25 | pgsql: Don't allow CREATE TABLE AS to put relations in pg_global. |