On Fri, Dec 13, 2019 at 12:10 PM vignesh C <vignesh21@gmail.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