Re: Toast issues with OldestXmin going backwards

On Sun, Apr 29, 2018 at 11:56 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Amit" == Amit Kapila <amit.kapila16@gmail.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