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

Hi

>
> What I am really wondering is why do we actually need to fix *two*
> problems at once? The first SetHintBits() looks like a no-brainer to
> me, and links to the second permutation in the test "s1_plain
> s1_count" where we do a CLUSTER after an UPDATE rollbacked to a
> previous savepoint. I don't think that there is a need for an
> isolation test on this one, either, wouldn't a plain SQL sequence be
> sufficient?
>

> So the first step to me would be a "Divide and Conquer" strategy,
> where we should look at each problem independently instead of trying
> to do too much at once.
Thank you for sorting the issue out and setting the direction. I was
thinking of leaving first SetHintBits() in
HeapTupleSatisfiesVacuumHorizon() and moving the second SetHintBits() to
heapam_relation_copy_for_cluster() to solve the performance issue.
However, it would still be another API violation, wouldn't it? We also
needs to figure out the multixact race issue. I'm trying to look into
multixact part as much as possible.

Regards,
Takeshi Ideriha