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