On Sat, Jan 30, 2021 at 8:23 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2021-01-28 11:14:03 +0530, Amit Kapila wrote: > > On Wed, Jan 27, 2021 at 9:38 AM Bharath Rupireddy > > <bharath.rupireddyforpostg...@gmail.com> wrote: > > > > > > On Wed, Jan 27, 2021 at 7:48 AM Zhihong Yu <z...@yugabyte.com> wrote: > > > > > > Thanks for pointing to the changes in the commit message. I corrected > > > them. Attaching v4 patch set, consider it for further review. > > > > > > > About 0001, have we tried to reproduce the actual bug here which means > > when the error_callback is called we should face some problem? I feel > > with the correct testcase we should hit the Assert > > (Assert(IsTransactionState());) in SearchCatCacheInternal because > > there we expect the transaction to be in a valid state. I understand > > that the transaction is in a broken state at that time but having a > > testcase to hit the actual bug makes it easy to test the fix. > > I think it's easy to hit - add a trivial DEBUG message to XLogWrite(), > and run anything involving logical rep using a low enough log > level. There might even be enough messages with a low enough level > already somewhere in the relevant paths.
I'm not sure how adding a DEBUG message to XLogWrite() would ensure the logical replication worker on the subscriber system enters slot_store_error_callback and hits the Assert(IsTransactionState());? Could you please elaborate? Or I may be missing something here to understand. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
