On Tue, Mar 21, 2017 at 12:15 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers