Re: VACUUM can finish an interrupted nbtree page split -- is that okay?
От | Peter Geoghegan |
---|---|
Тема | Re: VACUUM can finish an interrupted nbtree page split -- is that okay? |
Дата | |
Msg-id | CAH2-WzkLs_C22sGZRtPBGwq0OpacQ9F9PV3rrd3QqhhD_3DNNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: VACUUM can finish an interrupted nbtree page split -- is that okay? (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: VACUUM can finish an interrupted nbtree page split -- is that okay?
|
Список | pgsql-hackers |
On Mon, May 13, 2019 at 9:09 PM Peter Geoghegan <pg@bowt.ie> wrote: > 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. Actually, now that I look back at how page deletion worked 5+ years ago, I realize that I have this slightly wrong: the leaf level check is not sufficient to figure out if the parent's right sibling is pending deletion (which is represented explicitly as a half-dead internal page prior to 9.4). All the same, I'm going to push ahead with this patch. Bugfix commit efada2b8e92 was always about a bug in 9.4 -- it had nothing to do with 9.3. And, in the unlikely event that there is a problem on a pg_upgrade'd 9.3 -> 12 database that happens to have half-dead internal pages, we'll still get a useful, correct error from VACUUM one way or another. It might be slightly less friendly as error messages about corruption go, but that seems acceptable to me. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: