Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction

Hi Michael,

When I withdrew the patch, I said that if I came back to this, it
would start from an account of the problem and not from another
variant. Here it is.

There is a case that no hint bit can prevent: the pg_class row of a
table committed long ago is lost when the subtransaction that
updated it aborts while VACUUM FULL pg_class is between the old and
the new version. The attached script reproduces it with plain SQL,
using the progress view to time the ROLLBACK TO. It loses the row
in every round on unmodified master, REL_18_STABLE and
REL_14_STABLE.

When the scan reads the old version, its updater is still running,
so there is nothing to set yet. heapam_relation_copy_for_cluster()
is right to find the new version dead, as its inserter aborted.
What is wrong is what rewrite_heap_dead_tuple() concludes from that:
that the old version is dead too, which only holds if the update
committed. pruneheap.c draws that conclusion only from a
RECENTLY_DEAD tuple.

So instead of one more condition in rewrite_heap_dead_tuple(), the
fix removes it: dead tuples are no longer passed to rewriteheap.c,
and a tuple left waiting for a version that was never written is
resolved in end_heap_rewrite(), once the outcome of its update is
final. The code change removes more than it adds (71+, 77-); the
tests are a separate patch. I can post both if you want to look.

Manu