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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)
Date: 2024-04-10 21:28:43
Message-ID: 02c62e7e-df6b-4b50-8b9e-cdcb3b45c74e@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2024-04-10 21:36:00 Re: psql: Greatly speed up "\d tablename" when not using regexes
Previous Message Nathan Bossart 2024-04-10 21:23:44 allow changing autovacuum_max_workers without restarting