On Mon, May 13, 2019 at 8:30 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <p...@bowt.ie> writes: > > To be fair, I suppose that the code made more sense when it first went > > in, because at the time there was a chance that there could be > > leftover half-dead internal pages. But, that was a long time ago now. > > Is there a good reason to assume there are none left anywhere?
That is not an assumption that the proposed patch rests upon, though it is true that there are probably going to be virtually no half-dead internal pages that make there way on to a Postgres 12 installation. You'd have to do a CREATE INDEX on Postgres 9.3, and then not VACUUM or REINDEX the index once it was on a 9.4+ installation. I suppose that a 9.3 -> 12 upgrade is the most plausible scenario in which you could actual get a half-dead internal page on a Postgres 12 installation. Even when that happens, the index is already considered corrupt by VACUUM, so the same VACUUM process that could in theory be adversely affected by removing the half-dead internal page check will complain about the page when it gets to it later on -- the user will be told to REINDEX. And even then, we will never actually get to apply the check that I propose to remove, since we're already checking the leaf page sibling of the leaf-level target -- the leaf-level test that was added by efada2b8e92 was clearly necessary. But it was also sufficient (no equivalent internal half-dead right sibling test is needed): a 9.3-era half-dead internal page cannot have more than one child, which must be undergoing deletion as well. If somebody doubted my rationale for why we don't need to do anything more on internal page levels in installations where the user didn't pg_upgrade from a version that's < 9.4, then they'd still have to explain why we haven't heard of any problems in 5 years, and probably offer some alternative fix that considers "logically half-dead internal pages" (i.e. pages that are or will be the top parent in a deletion chain). Because the code that I propose to remove obviously cannot be doing much of anything for indexes built on 9.4+. -- Peter Geoghegan