From: | "Kumar, Sachin" <ssetiya(at)amazon(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | "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-16 16:56:38 |
Message-ID: | e56dcfa898794e82ac01c367df955451@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Peter,
> 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".
>
My assumption was the if subscriber is doing initial schema sync , It does not have
any conflicting database objects.
> 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.
Right
>
> 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"?
>
pg_dump does not support --if-not-exists , But I think it can be added and we get a
dump with IF NOT EXISTS.
On subscriber side we get table OID list, we can use this change table_state
= SUBREL_STATE_INIT so that it won't be recreated.
> ~~~
>
> 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?
DDL replication is needed to facilitate concurrent DDL, so that we don’t have to
worry about schema change at the same time when subscriber is initializing.
if we can block publisher so that it does not do DDLs or subscriber can simple
error out if it sees conflicting table information , then we don’t need to use DDL
replication.
Regards
Sachin
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | gkokolatos | 2023-03-16 17:04:16 | Re: Add LZ4 compression in pg_dump |
Previous Message | Andres Freund | 2023-03-16 16:36:48 | Re: Transparent column encryption |