Re: We need to log aborted autovacuums

On Sun, 2011-01-16 at 11:47 -0500, Tom Lane wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> > try_relation_open calls LockRelationOid, which blocks. There is also a
> > ConditionalLockRelationOid, which does the same basic thing except it
> > exits immediately, with a false return code, if it can't acquire the
> > lock. I think we just need to nail down in what existing cases it's
> > acceptable to have try_relation_oid use ConditionalLockRelationOid
> > instead, which would make it do what all us reading the code thought it
> > did all along.
>
> No, I don't believe we should be messing with the semantics of
> try_relation_open. It is what it is.
>
> The right way to fix this is similar to what LockTableRecurse does,
> ie call ConditionalLockRelationOid itself. I tried changing vacuum_rel
> that way yesterday, but the idea crashed when I realized that vacuum_rel
> doesn't have the name of the target relation, only its OID, so it can't
> log any very useful message ... and according to the original point of
> this thread, we're surely going to want an elog(LOG) when we can't get
> the lock.
>
> I think the best thing to do is probably to have autovacuum.c do the
> ConditionalLockRelationOid call before entering vacuum.c (making the
> later acquisition of the lock by try_relation_open redundant, but it
> will be cheap enough to not matter). But I haven't chased the details.

I'm fairly confused by this thread.

We *do* emit a message when we cancel an autovacuum task. We went to a
lot of trouble to do that. The message is DEBUG2, and says
"sending cancel to blocking autovacuum pid =".

We just need to make that LOG, not DEBUG2.

The autovacuum itself then says "canceling autovacuum task" when
canceled. It doesn't say what table the autovacuum was running on when
cancelled, but that seems like an easy thing to add since the AV does
know that.

I can't see any reason to differentiate between manually canceled AVs
and automatically canceled AVs. It's all the same thing.

Not really sure what it is you're talking about above or how that
relates to log messages for AV.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services