Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c) |
Дата | |
Msg-id | 20210818.172958.24378508451846000.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c) (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c) Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c) |
Список | pgsql-hackers |
At Tue, 17 Aug 2021 17:04:44 +0900, Michael Paquier <michael@paquier.xyz> wrote in > On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote: > > Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor < > > mahi6run@gmail.com> escreveu: > >> Please can we try to hit this rare condition by any test case. If you have > >> any test cases, please share. > > Yeah, this needs to be proved. Are you sure that this change is > actually right? The bottom of FreePageManagerPutInternal() has > assumptions that a page may not be found during a btree search, with > an index value used. By a quick look, FreePageBtreeSearch is called only from FreePageManagerPutInternal at three points. The first one assumes that result.found == true, at the rest points are passed only when fpm->btree_depth > 0, i.e, fpm->btree_root is non-NULL. In short FreePageBtreeSeach is never called when fpm->btree_root is NULL. I don't think we need to fill-in other members since the contract of the function looks fine. It might be simpler to turn 'if (btp == NULL)' to an assertion. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: