On Sun, Mar 9, 2025 at 9:00 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Tue, Mar 4, 2025 at 9:04 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > I see the point of adding such an option to avoid breaking the current > > applications (if there are any) that are relying on current behaviour. > > But OTOH, I am not sure if users expect us to fail explicitly in such > > scenarios. > > On the side note, with the patch since we ignore missing publications > we will be able to create a subscription with whatever publications > regardless their existence like: > > CREATE SUBSCRIPTION ... PUBLICATION pub1, pub2, pub3, pub4, pub5, ..., > pub1000; > > The walsender corresponding to such subscriber can stream changes as > soon as the listed publications are created on the publisher and > REFRESH PUBLICATION is executed. >
Right, but OTOH, one can expect that the data should start replicating as soon as one creates a publication on the publisher. However, the data for tables that are part of the publication will start replicating from the point when the decoding process will process the WAL corresponding to Create Publication. I suggest to add something for this in docs unless it is already explained. > > > > This is a long-standing behaviour for which we get reports from time > > to time, and once analyzing a failure, Tom also looked at it and > > agreed that we don't have much choice to avoid skipping non-existent > > publications [5]. But we never concluded as to whether skipping should > > be a default behavior or an optional one. So, we need more opinions on > > it. > > I'm leaning toward making the skipping behavior a default as I could > not find a good benefit for the current behavior (i.e., stopping > logical replication due to missing publications). > Sounds reasonable. We can always add the option at a later point if required. Thanks for your input. We can continue reviewing and committing the current patch. -- With Regards, Amit Kapila.
