Re: logical decoding and replication of sequences, take 2 - Mailing list pgsql-hackers

On Wed, Mar 29, 2023 at 7:58 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> On 3/29/23 11:51, Amit Kapila wrote:
> >>
> >> It's not clear to me what should be the exact behavior?
> >>
> >> I mean, imagine we're opening a connection for logical replication, and
> >> the subscriber does not handle sequences. What should the publisher do?
> >>
> >
> > I think deciding anything at the publisher would be tricky but won't
> > it be better if by default we disallow connection from subscriber to
> > the publisher when the publisher's version is higher? And then allow
> > it only based on some subscription option or maybe by default allow
> > the connection to a higher version but based on option disallows the
> > connection.
> >
> >>
> >> Speaking of precedents, TRUNCATE is probably a better one, because it's
> >> a new action and it determines *what* the subscriber can handle. But
> >> that does exactly the thing we do for sequences - if you open a
> >> connection from PG10 subscriber (truncate was added in PG11), and the
> >> publisher decodes a truncate, subscriber will do:
> >>
> >> 2023-03-28 20:29:46.921 CEST [2357609] ERROR:  invalid logical
> >>    replication message type "T"
> >> 2023-03-28 20:29:46.922 CEST [2356534] LOG:  worker process: logical
> >>    replication worker for subscription 16390 (PID 2357609) exited with
> >>    exit code 1
> >>
> >> I don't see why sequences should do anything else.
> >>
> >
> > Is this behavior of TRUNCATE known or discussed previously? I can't
> > see any mention of this in the docs or commit message. I guess if we
> > want to follow such behavior it should be well documented so that it
> > won't be a surprise for users. I think we would face such cases in the
> > future as well. One of the similar cases we are discussing for DDL
> > replication where a higher version publisher could send some DDL
> > syntax that lower version subscribers won't support and will lead to
> > an error [1].
> >
>
> I don't know where/how it's documented, TBH.
>
> FWIW I agree the TRUNCATE-like behavior (failing on subscriber after
> receiving unknown message type) is a bit annoying.
>
> Perhaps it'd be reasonable to tie the "protocol version" to subscriber
> capabilities, so that a protocol version guarantees what message types
> the subscriber understands. So we could increment the protocol version,
> check it in pgoutput_startup and then error-out in the sequence callback
> if the subscriber version is too old.
>
> That'd be nicer in the sense that we'd generate nicer error message on
> the publisher, not an "unknown message type" on the subscriber.
>

Agreed. So, we can probably formalize this rule such that whenever in
a newer version publisher we want to send additional information which
the old version subscriber won't be able to handle, the error should
be raised at the publisher by using protocol version number.

--
With Regards,
Amit Kapila.