Re: logical decoding and replication of sequences, take 2 - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: logical decoding and replication of sequences, take 2
Date
Msg-id CAD21AoA=vzK9AWBSwFAJroyqt0dB6owHBm6YjDxdU_TTfhdOhw@mail.gmail.com
Whole thread Raw
In response to Re: logical decoding and replication of sequences, take 2  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: logical decoding and replication of sequences, take 2  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Request for comment on setting binary format output per session
Next
From: Peter Smith
Date:
Subject: Re: Data is copied twice when specifying both child and parent table in publication