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