From: | "Kumar, Sachin" <ssetiya(at)amazon(dot)com> |
---|---|
To: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Initial Schema Sync for Logical Replication |
Date: | 2023-03-24 15:04:01 |
Message-ID: | 5941f001e4e846aa9b3f3efa000351a0@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I am not if it's feasible to support the use case the replicate DDL to old
> subscriber.
>
+1
> First, I think the current publisher doesn't know the version number of
> client(subscriber) so we need to check the feasibility of same. Also, having
> client's version number checks doesn't seem to be a good idea.
>
> Besides, I thought about the problems that will happen if we try to support
> replicating New PG to older PG. The following examples assume that we
> support the DDL replication in the mentioned PG.
>
> 1) Assume we want to replicate from a newer PG to a older PG where
> partition
> table has not been introduced. I think even if the publisher is aware of
> that, it doesn't have a good way to transform the partition related
> command,
> maybe one could say we can transform that to inherit table, but I feel that
> introduces too much complexity.
>
> 2) Another example is generated column. To replicate the newer PG which
> has
> this feature to a older PG without this. I am concerned that is there a way
> to transform this without causing inconsistent behavior.
>
> Even if we decide to simply skip sending such unsupported commands or
> skip applying them, then it's likely that the following dml replication will
> cause data inconsistency.
>
> So, it seems we cannot completely support this use case, there would be
> some limitations. Personally, I am not sure if it's worth introducing
> complexity to support it partially.
>
+1
Regards
Sachin
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-03-24 15:07:42 | Re: Make ON_ERROR_STOP stop on shell script failure |
Previous Message | Euler Taveira | 2023-03-24 15:01:17 | Re: Initial Schema Sync for Logical Replication |