Re: logical decoding and replication of sequences, take 2

On Thu, Mar 30, 2023 at 12:01 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

+1

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com