Re: logical decoding and replication of sequences, take 2

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.

In response to

Browse pgsql-hackers by date

  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