pg.ddx.io  pgsql-general@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Zheng Li <zhengli10@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: rajesh singarapu <rajesh.rs0541@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>
Cc: Hou, Zhijie/侯 志杰 <houzj.fnst@fujitsu.com>
Subject: Re: Support logical replication of DDLs
Date: Mon, 9 May 2022 11:05:12 +0200
Message-ID: <202205090905.bjca3mtbeqcd@alvherre.pgsql> (raw)
In-Reply-To: <CAFiTN-sFwwk963MkeUipVn3Me8JdpH43Kd=nNbJMnv__jwXPcw@mail.gmail.com>

On 2022-May-08, Dilip Kumar wrote:

> On Sat, May 7, 2022 at 9:38 AM Amit Kapila <amit.kapila16@gmail.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/





view thread (449+ messages)  latest in thread

Message-ID: <202205090905.bjca3mtbeqcd@alvherre.pgsql>
Permalink:  ../202205090905.bjca3mtbeqcd@alvherre.pgsql/
Also on:    postgresql.org/message-id/202205090905.bjca3mtbeqcd@alvherre.pgsql

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-general@postgresql.org
  Cc: alvherre@alvh.no-ip.org, dilipbalaut@gmail.com, amit.kapila16@gmail.com, zhengli10@gmail.com, pgsql-hackers@lists.postgresql.org, rajesh.rs0541@gmail.com, itsajin@gmail.com, houzj.fnst@fujitsu.com
  Subject: Re: Support logical replication of DDLs
  In-Reply-To: <202205090905.bjca3mtbeqcd@alvherre.pgsql>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox