Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)
Date
Msg-id 6d7f757a-d431-42a0-99ae-6af55eabf106@iki.fi
Whole thread Raw
In response to Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)
Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)
List pgsql-hackers
On 11/04/2024 16:37, Ranier Vilela wrote:
> Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas 
> <hlinnaka@iki.fi <mailto: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> <mailto: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.

I don't much like adding extra runtime checks for "can't happen" 
scenarios either. Assertions would be more clear, but in this case the 
code would just segfault trying to dereference the NULL pointer, which 
is fine for a "can't happen" scenario.

Looking closer, when we identify an XID as a subtransaction, we:
- assign toplevel_xid,
- set RBTXN_IS_SUBXACT, and
- assign toptxn pointer.

ISTM the 'toplevel_xid' and RBTXN_IS_SUBXACT are redundant. 
'toplevel_xid' is only used in those two calls that do 
ReorderBufferTXNByXid(rb, txn->toplevel_xid,...), and you could replace 
those by following the 'toptxn' pointer directly. And RBTXN_IS_SUBXACT 
is redundant with (toptxn != NULL). So here's a patch to remove 
'toplevel_xid' and RBTXN_IS_SUBXACT altogether.

Amit, you added 'toptxn' in commit c55040ccd017; does this look right to 
you?

-- 
Heikki Linnakangas
Neon (https://neon.tech)

Attachment

pgsql-hackers by date:

Previous
From: "Andrey M. Borodin"
Date:
Subject: Re: UUID v7
Next
From: Dmitry Koterov
Date:
Subject: [MASSMAIL]In MacOS, psql reacts on SIGINT in a strange fashion (Linux is fine)