Re: problems with table corruption continued

> -----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