On Tue, Mar 21, 2017 at 12:15 PM, Robert Haas <robertmhaas@gmail.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
