Re: Initial Schema Sync for Logical Replication - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Initial Schema Sync for Logical Replication
Date
Msg-id CAHut+PtJN+2R-SZGbKfOAR1Vz9rA2SH3kShy2_0HEtKYQJnn9A@mail.gmail.com
Whole thread Raw
In response to Initial Schema Sync for Logical Replication  ("Kumar, Sachin" <ssetiya@amazon.com>)
Responses RE: Initial Schema Sync for Logical Replication
List pgsql-hackers
Hi,

I have a couple of questions.

Q1.

What happens if the subscriber already has some tables present? For
example, I did not see the post saying anything like "Only if the
table does not already exist then it will be created".

On the contrary, the post seemed to say SUBREL_STATE_CREATE 'c' would
*always* be set when this subscriber mode is enabled. And then it
seemed to say the table would *always* get re-created by the tablesync
in this new mode.

Won't this cause problems
- if the user wanted a slightly different subscriber-side table? (eg
some extra columns on the subscriber-side table)
- if there was some pre-existing table data on the subscriber-side
table that you now are about to re-create and clobber?

Or does the idea intend that the CREATE TABLE DDL that will be
executed is like "CREATE TABLE ... IF NOT EXISTS"?

~~~

Q2.

The post says. "DDL replication is required for this feature". And "It
should also have turned on publication of DDL commands."

It wasn't entirely clear to me why those must be a requirement. Is
that just to make implementation easier?

Sure, I see that the idea might have some (or maybe a lot?) of common
internal code with the table DDL replication work, but OTOH an
auto-create feature for subscriber tables seems like it might be a
useful feature to have regardless of the value of the publication
'ddl' parameter.

------
Kind Regards,
Peter Smith.
Fujitsu Australia.



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: "current directory" in a server error message
Next
From: Amit Kapila
Date:
Subject: Re: Simplify some codes in pgoutput