On Fri, Jan 15, 2021 at 2:46 PM japin <japi...@hotmail.com> wrote: > > > > > I'm sorry, the 0001 patch is totally wrong. If we have only one > > publication, it works, > > however, this is a special case. If we have multiple publication in one > > subscription, > > it doesn't work. Here is a usecase. > > > > Step (1) > > -- On publisher > > CREATE TABLE t1 (a int); > > CREATE TABLE t2 (a int); > > CREATE PUBLICATION mypub1 FOR TABLE t1 WITH (publish='insert'); > > CREATE PUBLICATION mypub2 FOR TABLE t2; > > > > Step (2) > > -- On subscriber > > CREATE TABLE t1 (a int); > > CREATE TABLE t2 (a int); > > CREATE SUBSCRIPTION mysub CONNECTION 'host=localhost port=5432 > > dbname=postgres' PUBLICATION mypub1, mypub2; > > > > Step (3) > > -- On publisher > > INSERT INTO t1 VALUES (1); > > > > Step (4) > > -- On subscriber > > SELECT * FROM t1; > > > > In step (4), we cannot get the records, because there has two publications > > in > > data->publications, so we will check one by one. > > The first publication is "mypub1" and entry->pubactions.pubinsert will be > > set > > true, however, in the second round, the publication is "mypub2", and we > > cannot > > find pub->oid in pubids (only oid of "mypub1"), so it will set all > > entry->pubactions > > to false, and nothing will be replicate to subscriber. > > > > My apologies! > > As I mentioned in previous thread, if there has multiple publications in > single subscription, it might lead data loss. > > When the entry got invalidated in rel_sync_cache_publication_cb(), I think we > should mark the pubactions to false, and let get_rel_sync_entry() recalculate > the pubactions. > > 0001 - modify as above described. > 0002 - do not change. > > Any thought? >
That sounds like a better way to fix and in fact, I was about to suggest the same after reading your previous email. I'll think more on this but in the meantime, can you add the test case in the patch as requested earlier as well. -- With Regards, Amit Kapila.
