Re: Toast issues with OldestXmin going backwards

On Sun, Apr 29, 2018 at 11:56 AM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>>>>>> "Amit" == Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>
> >>> (Or do we need to track it across restarts? maybe we do, to deal with
> >>> replication slaves without slots, or changes in parameters)
>
> >> Yeah, I'm worried that it might need to be persistent across restarts.
> >>
> >> One idea that occurred to me is to somehow record -- I guess in
> >> pg_class using non-transactional updates -- the last cutoff XID used
> >> to vacuum any given table. Then we could just make a rule that you
> >> can't vacuum the TOAST table with an XID that's newer than the last
> >> one used for the main table. That would preserve the property that
> >> you can vacuum the tables separately while avoiding dangling pointers.
>
> Amit> Won't this lead to a bloat in toast tables when there is a big
> Amit> difference between the cutoff XID of the main heap table and the
> Amit> latest values of OldestXmin?
>
> Yes. What we need is actually the reverse of what Robert describes -
> when we vacuum the _main_ table, we must use the _later_ of the
> currently calculated OldestXmin or the OldestXmin last used to vacuum
> the toast table.
>

I think then that same formula needs to be used during cluster as
well. Also what about get_actual_variable_range(), will also need
similar change, is it okay to add additional lookup of pg_class in
that code path?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com