Re: Toast issues with OldestXmin going backwards

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Toast issues with OldestXmin going backwards
Дата
Msg-id CAA4eK1LiDKsh3yDLZHnUx=BMtg7RkPqeE8E57hTdC3+nVRztwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Toast issues with OldestXmin going backwards  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Toast issues with OldestXmin going backwards  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
On Fri, Apr 27, 2018 at 8:33 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Apr 26, 2018 at 9:03 PM, Andrew Gierth
> <andrew@tao11.riddles.org.uk> wrote:
>>    (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.
>

Won't this lead to a bloat in toast tables when there is a big
difference between the cutoff XID of the main heap table and the
latest values of OldestXmin?  As both the tables can be vacuumed
separately, it doesn't sound impossible, but maybe in some later pass
on main heap and toast table will fix the situation.  Even if the
difference is not big, vacuum might still be not able to remove rows
from toast table in some situations.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Charles Cui
Дата:
Сообщение: GSoC 2018: thrift encoding format
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Toast issues with OldestXmin going backwards