"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
