On Fri, Dec 13, 2019 at 12:10 PM vignesh C <vignes...@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
0001-Fix-subscriber-invalid-memory-access-on-DDL.amit.1.patch
Description: Binary data
