Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)
Дата
Msg-id CAEudQAop7_XOPXwAozbyyugHw+Ca5Lur5hRo3SrusRLwV7n8Ng@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas <hlinnaka@iki.fi> escreveu:
On 11/04/2024 15:03, Ranier Vilela wrote:
> Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas
> <hlinnaka@iki.fi <mailto:hlinnaka@iki.fi>> escreveu:
>
>     On 10/04/2024 21:07, Ranier Vilela wrote:
>      > Hi,
>      >
>      > Per Coverity.
>      >
>      > The function ReorderBufferTXNByXid,
>      > can return NULL when the parameter *create* is false.
>      >
>      > In the functions ReorderBufferSetBaseSnapshot
>      > and ReorderBufferXidHasBaseSnapshot,
>      > the second call to ReorderBufferTXNByXid,
>      > pass false to *create* argument.
>      >
>      > In the function ReorderBufferSetBaseSnapshot,
>      > fixed passing true as argument to always return
>      > a valid ReorderBufferTXN pointer.
>      >
>      > In the function ReorderBufferXidHasBaseSnapshot,
>      > fixed by checking if the pointer is NULL.
>
>     If it's a "known subxid", the top-level XID should already have its
>     ReorderBufferTXN entry, so ReorderBufferTXN() should never return NULL.
>
> There are several conditions to not return NULL,
> I think trusting never is insecure.

Well, you could make it an elog(ERROR, ..) instead. But the point is
that it should not happen, and if it does for some reason, that's very
suprpising and there is a bug somewhere. In that case, we should *not*
just blindly create it and proceed as if everything was OK.
Thanks for the clarification.
I will then suggest improving robustness, 
but avoiding hiding any possible errors that may occur.

v1 patch attached.

best regards,
Ranier Vilela
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Typos in the code and README
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: SET ROLE documentation improvement