On Sat, Jun 15, 2019 at 1:39 PM Noah Misch <noah@leadboat.com> wrote:
> To me, this text implies a cautious DBA should amcheck every index. Reading
> the thread[1], I no longer think that. It's enough to monitor that VACUUM
> doesn't start failing persistently on any index. I suggest replacing this
> release note text with something like the following:
>
> Avoid writing erroneous btree index data that does not change query results
> but causes VACUUM to abort with "failed to re-find parent key". Affected
> indexes are rare; REINDEX fixes them.
>
> (I removed "key truncation during a page split" as being too technical for
> release notes.)
I agree that this isn't terribly significant in general. Your proposed
wording seems better than what we have now, but a reference to INCLUDE
indexes also seems like a good idea. They are the only type of index
that could possibly have the issue with page deletion/VACUUM becoming
confused. Even then, the risk seems minor, because there has to be an
OOM at precisely the wrong point.
If there was any kind of _bt_split() OOM in 11.3 that involved a
non-INCLUDE B-Tree index, then the OOM could only occur when we
allocate a temp page buffer. I verified that this causes no
significant issue for VACUUM. It is best avoided, since we still
"leak" the new page/buffer, although that is almost harmless.
--
Peter Geoghegan