Hi,
On 2018-04-21 14:16:27 +0100, Andrew Gierth wrote:
> >>>>> "Amit" == Amit Kapila <amit.kapila16@gmail.com> writes:
>
> Amit> (c) Change the logic during rewrite such that it can detect this
> Amit> situation and skip copying the tuple in the main table,
>
> So I dug into this one and it looks to me like the best approach. Here's
> a draft patch against 10-stable, if nobody can think of any showstoppers
> then I'll do the rest of the versions and commit them.
Please wait for a bit. This isn't a trivial change, and I would like to
wrap my head around it.
At the very least this seems like it could cause extreme slowdowns for
large tables that have the right update/delete patterns?
> + /*
> + * OldestXmin going backwards can mean we have a RECENTLY_DEAD row that
> + * contains toast pointers whose toast rows have already been vacuumed
> + * away (or in the worst but unlikely case, recycled). If so, then the
> + * row must really be dead to all snapshots that could access it, so
> + * treat it as DEAD instead.
> + */
How is it guaranteed that the recheck doesn't find a different toast
tuple at the relevant position?
Greetings,
Andres Freund
