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

Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> writes:
> PS: no such effects happens on 9.0.4
> I think it can be related to TOAST related changes in 9.0.6

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.

We could fix this by having toast_save_datum, in the place where it
decides to adopt an old toast OID for the value (line 1345 in HEAD),
check to see if that OID already exists in the new table. If so, it
could either just assume that the value matches, or we could add enough
code to verify that there's a match. The latter seems like overkill,
and yet I'm not 100% comfortable with just assuming a collision is OK.
Comments?

regards, tom lane