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

"Hiroshi Inoue" <Inoue@tpf.co.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