Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, ranier(dot)vf(at)gmail(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)
Date: 2021-02-13 04:09:17
Message-ID: CALNJ-vQKuqFhYB-ZP3hwDQh5W8iaxKLS6Z4ZyY-tB=J-bNnSqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
How about the following patch ?

ReorderBufferSetBaseSnapshot() can return a bool to indicate whether the
base snapshot is set up.

For the call by SnapBuildCommitTxn(), it seems xid is top transaction. So
the return value doesn't need to be checked.

Cheers

On Fri, Feb 12, 2021 at 6:40 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Fri, Feb 12, 2021 at 03:56:02PM +0900, Kyotaro Horiguchi wrote:
> > If the return from the first call is a subtransaction, the second call
> > always obtain the top transaction. If the top transaction actualy did
> > not exist, it's rather the correct behavior to cause SEGV, than
> > creating a bogus rbtxn. THus it is wrong to set create=true and
> > create_as_top=true. We could change the assertion like Assert (txn &&
> > txn->base_snapshot) to make things clearer.
>
> I don't see much the point to change this code. The result would be
> the same: a PANIC at this location.
> --
> Michael
>

Attachment Content-Type Size
reorder-buffer-base-snapshot.patch application/octet-stream 2.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-02-13 04:24:08 Re: Why do we have MakeSingleTupleTableSlot instead of not using MakeTupleTableSlot?
Previous Message Masahiko Sawada 2021-02-13 03:18:36 Re: [PoC] Non-volatile WAL buffer