Re: BUG #6393: cluster sometime fail under heavy concurrent write load

I wrote:
> Yes, this is a consequence of commit
> 44b6d53b467bfe848c34c7a8a174779bb2f43c39, which tried to preserve toast
> OIDs when doing a table rewrite. The problem is that CLUSTER needs to
> copy both the old and new versions of an updated row, since the old one
> is only "recently dead", and both of those versions are pointing at the
> same TOAST item because the update didn't affect the toasted column.
> So when we save those versions into the new table separately, we try to
> write the same TOAST item twice.

BTW, it strikes me that the preceding implementation had its own bug in
this area: in the same situation of having to copy multiple versions of
a row, it would create independent copies of the referenced TOAST value.
Not only is this space-wasteful, but the copies attached to the
already-dead row versions would never be reclaimed, at least not short
of another CLUSTER, because they would be inserted into the toast table
as live not deleted rows.

So preserving toast item OIDs and relying on them for duplicate
detection actually will improve matters in a way unrelated to the
original purpose of commit 44b6d53b467bfe848c34c7a8a174779bb2f43c39.

regards, tom lane