Re: Toast issues with OldestXmin going backwards

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Toast issues with OldestXmin going backwards
Date: 2018-04-27 15:03:01
Message-ID: CA+TgmoaiCVOg_auyBKQOrSiaNwitQkY__NkwKwTVyosPZAkNfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 26, 2018 at 9:03 PM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)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.
But that's obviously not back-patchable, and it sounds finicky to get
right. It's really too bad that heap tables don't include a metapage
where we could store details like this...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2018-04-27 15:03:06 Re: documentation is now XML
Previous Message Peter Eisentraut 2018-04-27 15:00:36 Re: documentation is now XML