From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Zheng Li <zhengli10(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, rajesh singarapu <rajesh(dot)rs0541(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com> |
Subject: | Re: Support logical replication of DDLs |
Date: | 2022-05-09 09:05:12 |
Message-ID: | 202205090905.bjca3mtbeqcd@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 2022-May-08, Dilip Kumar wrote:
> On Sat, May 7, 2022 at 9:38 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > I agree that it adds to our maintainability effort, like every time we
> > enhance any DDL or add a new DDL that needs to be replicated, we
> > probably need to change the deparsing code. But OTOH this approach
> > seems to provide better flexibility. So, in the long run, maybe the
> > effort is worthwhile. I am not completely sure at this stage which
> > approach is better but I thought it is worth evaluating this approach
> > as Alvaro and Robert seem to prefer this idea.
>
> +1, IMHO with deparsing logic it would be easy to handle the mixed DDL
> commands like ALTER TABLE REWRITE. But the only thing is that we will
> have to write the deparsing code for all the utility commands so there
> will be a huge amount of new code to maintain.
Actually, the largest stumbling block on this, IMO, is having a good
mechanism to verify that all DDLs are supported. The deparsing code
itself is typically not very bad, as long as we have a sure way to twist
every contributor's hand into writing it, which is what an automated
test mechanism would give us.
The code in test_ddl_deparse is a pretty lame start, not nearly good
enough by a thousand miles. My real intention was to have a test
harness that would first run a special SQL script to install DDL
capture, then run all the regular src/test/regress scripts, and then at
the end ensure that all the DDL scripts were properly reproduced -- for
example transmit them to another database, replay them there, and dump
both databases and compare them. However, there were challenges which I
no longer remember and we were unable to complete this, and we are where
we are.
Thanks for rebasing that old code, BTW.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Durumdara | 2022-05-09 11:27:30 | Re: PLPGSQL - extra column existence in trigger |
Previous Message | Amit Kapila | 2022-05-09 08:56:03 | Re: Support logical replication of DDLs |
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-05-09 09:20:21 | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |
Previous Message | Peter Eisentraut | 2022-05-09 08:56:15 | Indent protocol.sgml |