Message-ID: <02c62e7e-df6b-4b50-8b9e-cdcb3b45c74e@iki.fi>
Date: Thu, 11 Apr 2024 00:28:43 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix possible dereference null pointer
 (src/backend/replication/logical/reorderbuffer.c)
Content-Language: en-US
To: Ranier Vilela <ranier.vf@gmail.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
References: <CAEudQApm0Kffq4GKLdyogyW1tVbkHOOqWTWg169OTsm1W=FUHg@mail.gmail.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <CAEudQApm0Kffq4GKLdyogyW1tVbkHOOqWTWg169OTsm1W=FUHg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/02c62e7e-df6b-4b50-8b9e-cdcb3b45c74e%40iki.fi>
Precedence: bulk

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)