Re: Support logical replication of DDLs

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Support logical replication of DDLs
Дата
Msg-id CAA4eK1KGUyAh5_UG=RvhbeQh-aHvtgb4tsZY-5fb1Yw29FSrHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support logical replication of DDLs  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Support logical replication of DDLs
Список pgsql-hackers
On Tue, Mar 29, 2022 at 9:47 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > The idea is to force skipping any direct data population (which can
> > potentially cause data inconsistency on the subscriber)
> > in CREATE AS and SELECT INTO command on the subscriber by forcing the
> > skipData flag in the intoClause of the parsetree after
> > the logical replication worker parses the command. The data sync will
> > be taken care of by the DML replication after the DDL replication
> > finishes.
>
> Okay, something like that should work, I am not sure it is the best
> design though.
>

Even if this works, how will we make Alter Table statement work where
it needs to rewrite the table? There also I think we can face a
similar problem if we directly send the statement, once the table will
be updated due to the DDL statement and then again due to table
rewrite as that will have a separate WAL.

Another somewhat unrelated problem I see with this work is how to save
recursion of the same command between nodes (when the involved nodes
replicate DDLs). For DMLs, we can avoid that via replication origins
as is being done in the patch proposed [1] but not sure how will we
deal with that here?

[1] - https://commitfest.postgresql.org/38/3610/

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gilles Darold
Дата:
Сообщение: Re: [Proposal] vacuumdb --schema only
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg14 psql broke \d datname.nspname.relname