Thread: HOT and autovacuum
Hi, I'm seeing a 8.3 database whose autovacuum-initiated vacuums are being cancelled and I am not sure of the cause. I am wondering if a HOT cleanup round on a page could try to acquire locks on it that would conflict with autovacuum (basically anything that conflicts with a vacuum lock). This would cause autovacuum to commit hara-kiri. If the table is frequently updated and HOT is invoked often, this could be very frequent. The auto-cancel feature of autovacuum is IMHO, in this case, not welcome. Perhaps we could teach autovac to not cancel itself if the other locker is a HOT page prune? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes: > I'm seeing a 8.3 database whose autovacuum-initiated vacuums are being > cancelled and I am not sure of the cause. I am wondering if a HOT > cleanup round on a page could try to acquire locks on it that would > conflict with autovacuum (basically anything that conflicts with a > vacuum lock). This would cause autovacuum to commit hara-kiri. This is nonsense, no? A buffer cleanup lock is an LWLock not a lock manager lock. regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > I'm seeing a 8.3 database whose autovacuum-initiated vacuums are being > > cancelled and I am not sure of the cause. I am wondering if a HOT > > cleanup round on a page could try to acquire locks on it that would > > conflict with autovacuum (basically anything that conflicts with a > > vacuum lock). This would cause autovacuum to commit hara-kiri. > > This is nonsense, no? A buffer cleanup lock is an LWLock not a lock > manager lock. Yeah, I realized that after awhile. There must be something else they are doing. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support