> -----Original Message-----
> From: Tom Lane
>
> "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> >> I would say that it's incorrect for vacuum.c to assume that
> >> HEAP_XMIN_COMMITTED can't become set on HEAP_MOVED_OFF/HEAP_MOVED_IN
> >> tuples during the course of vacuum's processing; after all, the xmin
> >> definitely does refer to a committed xact, and we can't realistically
> >> assume that we know what processing will be induced by user-defined
> >> index functions. Vadim, what do you think? How should we fix this?
>
> > But it's incorrect for table scan to mark tuple as good neither.
>
> Oh, that makes sense.
>
> > Looks like we have to add checks for the case
> > TransactionIdIsCurrentTransactionId(tuple->t_cmin) when
> > there is HEAP_MOVED_OFF or HEAP_MOVED_IN in t_infomask to
> > all HeapTupleSatisfies* in tqual.c as we do in
> > HeapTupleSatisfiesDirty - note comments about uniq btree-s there.
Should the change be TransactionIdIsInProgress(tuple->t_cmin) ?
The cause of Brian's issue was exactly what I was afraid of.
VACUUM is guarded by AccessExclusive lock but IMHO we
shouldn't rely on it too heavily.
regards,
Hiroshi Inoue