Re: segmentation fault when cassert enabled

On Fri, Dec 13, 2019 at 12:10 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> I have made changes to fix the comment provided. The patch for the
> same is attached. Could not add a test case for this scenario is based
> on timing issue.
> Thoughts?
>

I agree that this is a timing issue. I also don't see a way to write
a reproducible test for this. However, I could reproduce it via
debugger consistently by following the below steps. I have updated a
few comments and commit messages in the attached patch.

Peter E., Petr J or anyone else, do you have comments or objections on
this patch? If none, then I am planning to commit (and backpatch)
this patch in a few days time.

Test steps to reproduce the issue.
Set up
---------
set up master and subscriber nodes.
In code, add a while(true) in apply_handle_update() before a call to
logicalrep_rel_open(). This is to ensure that we can debug the replay
of Update
operation on subscriber.

Master
-----------
Create table t1(c1 int);
Create publication pub_t1 for table t1;
Alter table t1 replica identity full;

Subscriber
-------------
Create table t1(c1 int);
CREATE SUBSCRIPTION sub_t1 CONNECTION 'host=localhost port=5432
dbname=postgres' PUBLICATION pub_t1;

Master
----------
Insert into t1 values(1); --this will create LogicalRepRelMap entry
for t1 on subscriber.

Subscriber
----------
Select * from t1; -- This should display the data inserted in master.

Master
----------
Update t1 set c1 = 2 where c1=1;

Now on the subscriber, attach a debugger and debug logicalrep_rel_open
and stop debugger just before table_open call.

Subscriber
-----------
Alter table t1 add c2 int;

Now, continue in debugger, it should crash in slot_store_cstrings()
because the rel->attrmap is not updated.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com