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
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 |