W dniu 20.01.2016, śro o godzinie 13∶54 +0800, użytkownik Craig Ringer napisał: > On 20 January 2016 at 06:23, Tomasz Rybak <tomasz.ry...@post.pl> > wrote: > > The following review has been posted through the commitfest > > application: > > > Thanks! > > > > > + /* Protocol capabilities */ > > + #define PGLOGICAL_PROTO_VERSION_NUM 1 > > + #define PGLOGICAL_PROTO_MIN_VERSION_NUM 1 > > Is this protocol version number and minimal recognized version > > number, > > or major and minor version number? I assume that > > PGLOGICAL_PROTO_VERSION_NUM > > is current protocol version (as in config max_proto_version and > > min_proto_version). But why we have MIN_VERSION and not > > MAX_VERSION? > > > > From code in pglogical_output.c (lines 215-225 it looks like > > PGLOGICAL_PROTO_VERSION_NUM is maximum, and > > PGLOGICAL_PROTO_MIN_VERSION_NUM > > is treated as minimal protocol version number. > > > > I can see that those constants are exported in > > pglogical_infofuncs.c and > > pglogical.sql, but I do not understand omission of MAX. > Thanks for stopping to think about this. It's one of the areas I > really want to get right but I'm not totally confident of. > > The idea here is that we want downwards compatibility as far as > possible and maintainable but we can't really be upwards compatible > for breaking protocol revisions. So the output plugin's native > protocol version is inherently the max protocol version and we don't > need a separate MAX. > > The downstream connects and declares to the upstream "I speak > protocol 2 through 3". The upstream sees this and replies "I speak > protocol 1 through 2. We have protocol 2 in common so I will use > that." Or alternately replies with an error "I only speak protocol 1 > so we have no protocol in common". This is done via the initial > parameters passed by the downstream to the logical decoding plugin > and then via the startup reply message that's the first message on > the logical decoding stream. > > We can't do a better handshake than this because the underlying > walsender protocol and output plugin API only gives us one chance to > send free-form information to the output plugin and it has to do so > before the output plugin can send anything to the downstream. > > As much as possible I want to avoid ever needing to do a protocol > bump anyway, since it'll involve adding conditionals and duplication. > That's why the protocol tries so hard to be extensible and rely on > declared capabilities rather than protocol version bumps. But I'd > rather plan for it than be unable to ever do it in future. > > Much (all?) of this is discussed in the protocol docs. I should > probably double check that and add a comment that refers to them > there. >
Thanks for explanation. I'll think about it more and try to propose something for this. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
