Greg Smith <greg@2ndquadrant.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.
regards, tom lane
