From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Toast issues with OldestXmin going backwards |
Date: | 2018-04-29 06:26:56 |
Message-ID: | 878t96a61e.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "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.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-04-29 10:35:37 | Re: Postgres, fsync, and OSs (specifically linux) |
Previous Message | Amit Kapila | 2018-04-29 06:14:39 | Re: Toast issues with OldestXmin going backwards |