From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> |
Subject: | Re: GUC for cleanup indexes threshold. |
Date: | 2017-03-22 00:18:24 |
Message-ID: | CAH2-Wznft2DDntOp_5Zdz_CBHmZf2oeWR-PCHXrYBP9zAof4kQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 21, 2017 at 12:15 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Wouldn't it break on-disk compatibility with existing btree indexes?
Yes, it would, but see my later remarks on pd_prune_xid. I think that
that would be safe.
> I think we're still trying to solve a problem that Simon postulated in
> advance of evidence that shows how much of a problem it actually is.
I don't think we're still doing that. I think we're discussing the
risk of recycling being broken indefinitely when it doesn't happen in
time.
> Not only might that be unnecessary, but if we don't have a test
> demonstrating the problem, we also don't have a test demonstrating
> that a given approach fixes it.
Preventing recycling from happening until we feel like it is probably
fine. It is not fine to break it forever, though. The specific problem
is that there is an XID stored in dead B-Tree + SP-GiST pages that is
used in the subsequent RecentGlobalXmin interlock that determines if
recycling is safe (if there is no possible index scan that could land
on the dead page). You know, the _bt_page_recyclable() check.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-03-22 00:44:35 | Re: Parallel tuplesort (for parallel B-Tree index creation) |
Previous Message | Michael Banck | 2017-03-22 00:15:55 | Re: Create replication slot in pg_basebackup if requested and not yet present |