Re: We need to log aborted autovacuums

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We need to log aborted autovacuums
Date: 2011-01-16 18:20:54
Message-ID: 10073.1295202054@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> Simon Riggs wrote:
>> I'm fairly confused by this thread.

> That's becuase you think it has something to do with cancellation, which
> it doesn't. The original report here noted a real problem but got the
> theorized cause wrong.

I think that cancellations are also a potentially important issue that
could do with being logged. The issue that I see is that if an
application has a use-pattern that involves obtaining exclusive lock on
a large table fairly frequently, then AV will never be able to complete
on that table, leading to bloat and eventual XID wraparound issues.
Once we get scared about XID wraparound, AV will refuse to let itself
be canceled, so it will prevent the wraparound ... at the cost of
denying service to the application code path that wants the lock.
So this is the sort of thing that it'd be good to have some bleating
about in the log, giving the DBA a chance to rethink the app's locking
behavior before the consequences get nasty.

But, having said that, false alarms in the log are not nice. So I'd
rather have the LOG messages coming out from actual transaction aborts
in AV, not from the remote end of the signal.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-01-16 18:21:29 Re: pg_basebackup for streaming base backups
Previous Message Magnus Hagander 2011-01-16 18:16:14 Re: Include WAL in base backup