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)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: tushar
Дата:
Сообщение: Re: refactoring basebackup.c
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Add connection active, idle time to pg_stat_activity