Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas <hlinn...@iki.fi> escreveu:
> On 11/04/2024 15:03, Ranier Vilela wrote: > > Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas > > <hlinn...@iki.fi <mailto:hlinn...@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
v1-fix-possible-dereference-null-pointer-reorderbuffer.patch
Description: Binary data
