On Thu, Mar 30, 2023 at 12:01 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Mar 29, 2023 at 7:58 PM Tomas Vondra > <tomas.von...@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
