Re: logical decoding and replication of sequences, take 2

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Amit Kapila <amit.kapila16@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-27T01:32:27Z
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"

Hi,

On Fri, Mar 24, 2023 at 7:26 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> I merged the earlier "fixup" patches into the relevant parts, and left
> two patches with new tweaks (deducing the corrent "WAL" state from the
> current state read by copy_sequence), and the interlock discussed here.
>

Apart from that, how does the publication having sequences work with
subscribers who are not able to handle sequence changes, e.g. in a
case where PostgreSQL version of publication is newer than the
subscriber? As far as I tested the latest patches, the subscriber
(v15)  errors out with the error 'invalid logical replication message
type "Q"' when receiving a sequence change. I'm not sure it's sensible
behavior. I think we should instead either (1) deny starting the
replication if the subscriber isn't able to handle sequence changes
and the publication includes that, or (2) not send sequence changes to
such subscribers.

Regards,

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