Re: Toast issues with OldestXmin going backwards

Hi,

On 2018-04-21 14:16:27 +0100, Andrew Gierth wrote:
> >>>>> "Amit" == Amit Kapila <amit(dot)kapila16(at)gmail(dot)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