Обсуждение: 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