Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
От | Greg Nancarrow |
---|---|
Тема | Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c) |
Дата | |
Msg-id | CAJcOf-d7pRy7rJcb47HExUmPCqyuuwjps5Jt1uDRbL9H31hLiQ@mail.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)
|
Список | pgsql-hackers |
On Thu, Jan 27, 2022 at 6:32 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Fri, Oct 01, 2021 at 05:03:04PM -0300, Ranier Vilela wrote: > > For me the assertion remains valid and usable. > > Well, I was looking at this thread again, and I still don't see what > we benefit from this change. One thing that could also be done is to > initialize "result" at {0} at the top of FreePageManagerGetInternal() > and FreePageManagerPutInternal(), but that's in the same category as > the other suggestions. I'll go drop the patch if there are no > objections. Why not, at least, just add "Assert(result.page != NULL);" after the "Assert(!result.found);" in FreePageManagerPutInternal()? The following code block in FreePageBtreeSearch() - which lacks those initializations - should never be invoked in this case, and the added Assert will make this more obvious. if (btp == NULL) { result->page = NULL; result->found = false; return; } Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: