Re: logical decoding and replication of sequences, take 2

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, John Naylor <john.naylor@enterprisedb.com>, vignesh C <vignesh21@gmail.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: 2023-03-29T14:49:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Migrate logical slots to the new node during an upgrade.

  2. Make test_decoding ddl.out shorter

  3. Fix snapshot handling in logicalmsg_decode

  4. doc: Adjust a few more references to "postmaster"

  5. Revert "Logical decoding of sequences"

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.