Re: Fix for segfault in logical replication on master - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Fix for segfault in logical replication on master
Date
Msg-id CAA4eK1JPhyuORBiR-TBQJAue5U=h0+NH55z6hFi3eE7J-gKmvQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix for segfault in logical replication on master  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Fix for segfault in logical replication on master
List pgsql-hackers
On Thu, Jun 17, 2021 at 6:50 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
> > On Jun 17, 2021, at 3:39 AM, osumi.takamichi@fujitsu.com wrote:
> >
> > For the 1st check, isn't it better to use RelationIsValid() ?
>
> Yes, you are right.
>
> > Additionally, In what kind of actual scenario, did you think that
> > we come to the part to "log a complaint" ?
>
> The way that RelationGetIndexList assigns rd_replidindex to the Relation seems to lack sufficient locking.  After
scanningpg_index to find indexes associated with the relation, pg_index is closed and the access share lock released.
Icouldn't prove to myself that by the time we use the rd_replidindex field thus computed that it was safe to assume
thatthe Oid stored there still refers to an index.  The most likely problem would be that the index has since been
droppedin a concurrent transaction, but it also seems just barely possible that the Oid has been reused and refers to
somethingelse, a table perhaps. 
>

I think such a problem won't happen because we are using historic
snapshots in this context. We rely on that in a similar way in
reorderbuffer.c, see ReorderBufferProcessTXN.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: locking [user] catalog tables vs 2pc vs logical rep
Next
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions