From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | Brian Hirt <bhirt(at)mobygames(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>, Brian A Hirt <bhirt(at)berkhirt(dot)com> |
Subject: | Re: problems with table corruption continued |
Date: | 2001-12-18 19:36:11 |
Message-ID: | 17925.1008704171@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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.
Sounds like a plan. Do you want to work on this, or shall I?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Terrell | 2001-12-18 19:40:48 | Re: FreeBSD/alpha |
Previous Message | Tom Lane | 2001-12-18 19:32:05 | Re: problems with table corruption continued |