aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvacuum.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-03-21 13:04:07 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2012-03-21 13:04:55 -0400
commit5bd06e619c82c3b2e29fed40aae5fc39a9620908 (patch)
tree910e87570c38cc9c037a45b4d28c3098517db267 /src/backend/access/gist/gistvacuum.c
parent16f42be840bc7a96fb008055632388954c3548ba (diff)
downloadpostgresql-5bd06e619c82c3b2e29fed40aae5fc39a9620908.tar.gz
postgresql-5bd06e619c82c3b2e29fed40aae5fc39a9620908.zip
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
Diffstat (limited to 'src/backend/access/gist/gistvacuum.c')
0 files changed, 0 insertions, 0 deletions