Re: Toast issues with OldestXmin going backwards - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Toast issues with OldestXmin going backwards
Date
Msg-id CAA4eK1LiDKsh3yDLZHnUx=BMtg7RkPqeE8E57hTdC3+nVRztwA@mail.gmail.com
Whole thread Raw
In response to Re: Toast issues with OldestXmin going backwards  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Toast issues with OldestXmin going backwards  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List 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 by date:

Previous
From: Charles Cui
Date:
Subject: GSoC 2018: thrift encoding format
Next
From: Andrew Gierth
Date:
Subject: Re: Toast issues with OldestXmin going backwards