Robert Haas wrote: > On Sat, Nov 29, 2014 at 11:46 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > > What do you mean by "never succeed"? Is it skipping a large number of pages? > > Might re-trying the locks within the same vacuum help, or are the user locks > > too persistent? > > You are confused. He's talking about the relation-level lock that > vacuum attempts to take before doing any work at all on a given table, > not the per-page cleanup locks that it takes while processing each > page. If the relation-level lock can't be acquired, the whole table > is skipped.
Almost there. Autovacuum takes the relation-level lock, starts processing. Some time later, another process wants a lock that conflicts with the one autovacuum has. This is flagged by the deadlock detector, and a signal is sent to autovacuum, which commits suicide. If the table is large, the time window for this to happen is large also; there might never be a time window large enough between two lock acquisitions for one autovacuum run to complete in a table. This starves the table from vacuuming completely, until things are bad enough that an emergency vacuum is forced. By then, the bloat is disastrous. I think it's that suicide that Andres wants to disable. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
