vignesh C <vignesh21@gmail.com> writes:
> On Fri, 6 Jan 2023 at 04:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm. I spent some time cleaning up this patch, and found that there's
>> still a problem. ISTM that the row with value "3" ought to end up
>> in the subscriber's sch2.t1 table, but it does not: the attached
>> test script fails with
>> ...
>> What's up with that?
> When the subscription is created, the subscriber will create a
> subscription relation map of the corresponding relations from the
> publication. The subscription relation map will only have sch1.t1
> entry. As sch2.t1 was not present in the publisher when the
> subscription was created, subscription will not have this entry in the
> subscription relation map. So the insert operations performed on the
> new table sch2.t1 will not be applied by the subscriber. We will have
> to refresh the publication using 'ALTER SUBSCRIPTION ... REFRESH
> PUBLICATION' to fetch missing table information from publisher. This
> will start replication of tables that were added to the subscribed-to
> publications since CREATE SUBSCRIPTION or the last invocation of
> REFRESH PUBLICATION.
But ... but ... but ... that's the exact opposite of what the test
case shows to be happening. To wit, the newly created table
(the second coming of sch1.t1) *is* replicated immediately, while
the pre-existing t1 (now sch2.t1) is not. It's impossible to
explain those two facts under either a model of "tables are matched
by name" or "tables are matched by OID". So I'm still of the opinion
that there's some very dubious behavior here.
However, it does seem that the cache flush makes one aspect better,
so I pushed this after a little further work on the test case.
regards, tom lane
