Re: Draft back-branch release notes are up for review
От | Peter Geoghegan |
---|---|
Тема | Re: Draft back-branch release notes are up for review |
Дата | |
Msg-id | CAH2-Wz=aS55icTibP5k+5=j=mHOzQ-Wd8i4jMrVx66g2-g+-Qw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Draft back-branch release notes are up for review (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Draft back-branch release notes are up for review
Re: Draft back-branch release notes are up for review |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: