Re: Toast issues with OldestXmin going backwards
От | Andrew Gierth |
---|---|
Тема | Re: Toast issues with OldestXmin going backwards |
Дата | |
Msg-id | 878t96a61e.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Toast issues with OldestXmin going backwards (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Toast issues with OldestXmin going backwards
|
Список | pgsql-hackers |
>>>>> "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. -- Andrew (irc:RhodiumToad)
В списке pgsql-hackers по дате отправления: