
> The tuple toaster currently fetches toast-table rows using SnapshotAny.
> This is quite uncool, because it will in fact find *any* row.

Well, doesn't it need to find *any* row, since the accesses to heap and toast
are not "atomic" (not interlocked) ?

>  Including dead rows resulting from an aborted

But then also the heap tuple is aborted, and thus a normal select will not
select that toast anyway.

> (or, in 7.2, still-in-progress)
> VACUUM.

I thought new vacuum did not move tuples ? Why should it then produce 
two rows ? And VACUUM FULL locks the table so ...

I think SnapshotSelf could have concurrency problems (not see a toast
that someone else committed between our heap read and toast read)
IIRC, at the time at least SnapshotAny was chosen on purpose.

Might it be a problem, that VACUUM sets xids to FrozenXid, and we always
consider that one Valid, even if that vacuum is still in progress ? 

I can only see a problem with a partway through vacuum full, that aborted.

Andreas

PS: short desc between Any and Self, anybody ?

Wed, 16 Jan 2002 18:24:53 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: tuptoaster.c must *not* use SnapshotAny
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> The tuple toaster currently fetches toast-table rows using SnapshotAny.
>> This is quite uncool, because it will in fact find *any* row.

> Well, doesn't it need to find *any* row, since the accesses to heap and toast
> are not "atomic" (not interlocked) ?

No; it needs to *not* find dead rows resulting from a failed vacuum.
You are right that for the most part TOAST relies on time qualification
of the main-table row, and no doubt that was why Jan thought he could
code it like this; but vacuuming the TOAST table is not an operation
that affects the main table.

>> Including dead rows resulting from an aborted

> But then also the heap tuple is aborted, and thus a normal select will not
> select that toast anyway.

Wrong; see above.  We are talking about reshuffling rows in the TOAST
table that belong (presumably) to a live row in the main table.  During
the VACUUM there will be more than one copy of such rows.

>> (or, in 7.2, still-in-progress)
>> VACUUM.

> I thought new vacuum did not move tuples ? Why should it then produce 
> two rows ? And VACUUM FULL locks the table so ...

You're right, lazy VACUUM doesn't create this issue.  My mistake.
But VACUUM FULL does.

> I can only see a problem with a partway through vacuum full, that aborted.

Exactly.

			regards, tom lane

Wed, 16 Jan 2002 12:29:45 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: tuptoaster.c must *not* use SnapshotAny 