Re: Using logical replication with older version subscribers

On Mon, Jan 7, 2019 at 9:01 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> Hi,
>
> Logical replication enables us to replicate data changes to different
> major version PostgreSQL as the doc says[1]. However the current
> logical replication can work fine only if replicating to a newer major
> version PostgreSQL such as from 10 to 11. Regarding using logical
> replication with older major version, say sending from 11 to 10, it
> will stop when a subscriber receives a truncate change because it's
> not supported at PostgreSQL 10. I think there are use cases where
> using logical replication with a subscriber of an older version
> PostgreSQL but I'm not sure we should support it.
>
> Of course in such case we can set the publication with publish =
> 'insert, update, delete' to not send truncate changes but it requres
> users to recognize the feature differences between major vesions and
> in the future it will get more complex. So I think it would be better
> to be configured autometically by PostgreSQL.
>
> To fix it we can make subscribers send its supporting message types to
> the publisher at a startup time so that the publisher doesn't send
> unsupported message types on the subscriber. Or as an another idea, we
> can make subscribers ignore unsupported logical replication message
> types instead of raising an error. Feedback is very welcome.
>
> [1] https://www.postgresql.org/docs/devel/logical-replication.html

How would that work in practice?

If an 11 server is sent a message saying "client does not support
truncate", and immediately generates an error, then you can no longer
replicate even if you turn off truncate. And if it delays it until the
actual replication of the item, then you just get the error on the primary
ìnstead of the standby?

I assume you are not suggesting a publication with truncation enabled
should just ignore replicating truncation if the downstream server doesn't
support it? Because if that's the suggestion, then a strong -1 from me on
that.

And definitely -1 for having a subscriber ignore messages it doesn't know
about. That's setting oneself up for getting invalid data on the
subscriber, because it skipped something that the publisher expected to be
done.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>