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 02c62e7e-df6b-4b50-8b9e-cdcb3b45c74e@iki.fi
Whole thread Raw
In response to [MASSMAIL] Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)  (Ranier Vilela <ranier.vf@gmail.com>)
List pgsql-hackers
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. 
It's not surprising if Coverity doesn't understand that, but setting the 
'create' flag doesn't seem like the right fix. If we add "Assert(txn != 
NULL)", does that silence it?

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




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: [MASSMAIL]allow changing autovacuum_max_workers without restarting
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: psql: Greatly speed up "\d tablename" when not using regexes