Re: logical decoding and replication of sequences, take 2

On 3/27/23 03:32, Masahiko Sawada wrote:
> Hi,
>
> On Fri, Mar 24, 2023 at 7:26 AM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)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.
>

I agree the "invalid message" error is not great, but it's not clear to
me how to do either (1). The trouble is we don't really know if the
publication contains (or will contain) sequences. I mean, what would
happen if the replication starts and then someone adds a sequence?

For (2), I think that's not something we should do - silently discarding
some messages seems error-prone. If the publication includes sequences,
presumably the user wanted to replicate those. If they want to replicate
to an older subscriber, create a publication without sequences.

Perhaps the right solution would be to check if the subscriber supports
replication of sequences in the output plugin, while attempting to write
the "Q" message. And error-out if the subscriber does not support it.

What do you think?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company