On Mon, Dec 18, 2023 at 11:35 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi, I had a look at the latest v02 patches.
>
> On Sat, Dec 16, 2023 at 12:36 AM Emre Hasegeli <emre@hasegeli.com> wrote:
> >
> > > OK, to deal with that can't you just include "origin" in the first
> > > group which has no special protocol requirements?
> >
> > I think it'd be confusing because the option is not available before
> > version 16. I think it should really check for the version number and
> > complain if it's less than 4.
>
> Hm. I don't think a proto_version check is required for "origin".
>
> IIUC, the protocol version number indicates the message byte format.
> It's needed so that those messages bytes can be read/written in the
> same/compatible way. OTOH I thought the "origin" option has nothing
> really to do with actual message formats on the wire; I think it works
> just by filtering up-front to decide either to send the changes or not
> send the changes. For example, so long as PostgreSQL >= v16, I expect
> you could probably use "origin" with any proto_version you wanted.
>
But, I don't know how the user would be able to arrange for such a
mixture of PG/proto_version versions. because they do seem tightly
coupled for pgoutput.
e.g.
server_version = walrcv_server_version(LogRepWorkerWalRcvConn);
options.proto.logical.proto_version =
server_version >= 160000 ?
LOGICALREP_PROTO_STREAM_PARALLEL_VERSION_NUM :
server_version >= 150000 ? LOGICALREP_PROTO_TWOPHASE_VERSION_NUM :
server_version >= 140000 ? LOGICALREP_PROTO_STREAM_VERSION_NUM :
LOGICALREP_PROTO_VERSION_NUM;
======
Kind Regards,
Peter Smith.
Fujitsu Australia