On Tue, May 3, 2022 at 12:10 AM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 5/2/22 19:51, Alvaro Herrera wrote: > >> Why would we need to know publications replicated by other walsenders? > >> And what if the subscriber is not connected at the moment? In that case > >> there'll be no walsender. > > > > Sure, if the replica is not connected then there's no issue -- as you > > say, that replica will fail at START_REPLICATION time. > > > > Right, I got confused a bit. > > Anyway, I think the main challenge is defining what exactly we want to > check, in order to ensure "sensible" behavior, without preventing way > too many sensible use cases. >
I could think of below two options: 1. Forbid any case where column list is different for the same table when combining publications. 2. Forbid if the column list and row filters for a table are different in the set of publications we are planning to combine. This means we will allow combining column lists when row filters are not present or when column list is the same (we don't get anything additional by combining but the idea is we won't forbid such cases) and row filters are different. Now, I think the points in favor of (1) are that the main purpose of introducing a column list are: (a) the structure/schema of the subscriber is different from the publisher, (b) want to hide sensitive columns data. In both cases, it should be fine if we follow (1) and from Peter E.'s latest email [1] he also seems to be indicating the same. If we want to be slightly more relaxed then we can probably (2). We can decide on something else as well but I feel it should be such that it is easy to explain. [1] - https://www.postgresql.org/message-id/47dd2cb9-4e96-169f-15ac-f9407fb54d43%40enterprisedb.com -- With Regards, Amit Kapila.
