Re: [BUG] "FailedAssertion" reported when streaming in logical replication - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [BUG] "FailedAssertion" reported when streaming in logical replication
Date
Msg-id CAFiTN-s9Dry7G_+RW8UxMrP=cOV610zwpcWLKOe8Y5PgzRm95Q@mail.gmail.com
Whole thread Raw
In response to Re: [BUG] "FailedAssertion" reported when streaming in logical replication  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses RE: [BUG] "FailedAssertion" reported when streaming in logical replication  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
List pgsql-hackers
On Wed, Apr 28, 2021 at 1:02 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Apr 28, 2021 at 12:25 PM tanghy.fnst@fujitsu.com
> <tanghy.fnst@fujitsu.com> wrote:
> >
> > > I have modified the patch based on the above comments.
> >
> > Thanks for your patch.
> > I tested again after applying your patch and the problem is fixed.
>
> Thanks for confirming.

I tried to think about how to write a test case for this scenario, but
I think it will not be possible to generate an automated test case for
this.  Basically, we need 2 concurrent transactions and out of that,
we need one transaction which just has processed only one change i.e
XLOG_HEAP2_NEW_CID and another transaction should overflow the logical
decoding work mem, so that we select the wrong transaction which
doesn't have the base snapshot.  But how to control that the
transaction which is performing the DDL just write the
XLOG_HEAP2_NEW_CID wal and before it writes any other WAL we should
get the WAl from other transaction which overflows the buffer.
-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication
Next
From: Amit Kapila
Date:
Subject: Re: Replication slot stats misgivings