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

Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
escreveu:

> On 11/04/2024 15:03, Ranier Vilela wrote:
> > Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas
> > <hlinnaka(at)iki(dot)fi <mailto:hlinnaka(at)iki(dot)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