On Tuesday, May 3, 2022 11:31 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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.
I also think it makes sense to add a restriction like (1). I am planning to implement the restriction if no one objects. Best regards, Hou zj
