From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
Subject: | Re: logical decoding and replication of sequences, take 2 |
Date: | 2023-03-29 14:49:04 |
Message-ID: | 8f3ab01d-3201-bac8-5151-3964f5fd0b2e@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29.03.23 16:28, Tomas Vondra wrote:
> 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 would make sense.
> 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. That's
> doable, the main problem being it'd be inconsistent with the TRUNCATE
> behavior. OTOH that was introduced in PG11, which is the oldest version
> still under support ...
I think at the time TRUNCATE support was added, we didn't have a strong
sense of how the protocol versioning would work or whether it would work
at all, so doing nothing was the easiest way out.
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2023-03-29 15:10:18 | Re: zstd compression for pg_dump |
Previous Message | Peter Eisentraut | 2023-03-29 14:46:16 | Re: cataloguing NOT NULL constraints |