Re: [HACKERS] Re: Concurrent VACUUM: first results

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> We couldn't get xids of not running *transaction*s because its proc->xid
> is set to 0(InvalidTransactionId). So blocking transaction couldn' find an
> xidLookupEnt in xidTable corresponding to the not running *transaction*
> when it tries to LockResolveConflicts() in LockReleaseAll() and couldn't
> GrantLock() to XidLookupEnt corresponding to the not running *transac
> tion*. After all LockAcquire() from not running *transaction* always fails
> once it is blocked.

OK, I can believe that ... I assumed that proc->xid still had the ID of
the last transaction, but if it's set to 0 during xact cleanup then this
behavior makes sense. Still, it seems like lock.c should detect the
missing table entry and fail sooner than it does ...

>> I suspect that
>> there is more to this that I don't understand. Why does calling
>> XactLockTableWait() with an already-committed XID cause the following
>> code in lock.c to trigger? Is this evidence of a logic bug in lock.c,
>> or at least of inadequate checks for bogus input?

> It's seems strange. Isn't it waiting for a being deleted tuple by vc_upd
> stats() in vc_vacone() ?

No --- the process that reaches the "INCONSISTENT" exit is the one that
is trying to do the deletion of pg_statistic rows (during VACUUM
startup). Presumably, it's found a row that is stored but not yet
committed by another VACUUM, and is trying to wait for that transaction
to commit.

regards, tom lane