Re: Support logical replication of DDLs

Поиск
Список
Период
Сортировка
От Zheng Li
Тема Re: Support logical replication of DDLs
Дата
Msg-id CAAD30ULBUSHG4n-_zZ7yLGPri-LkS0o+vp64WCKj-mFcF27ekg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Support logical replication of DDLs  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Ответы Re: Support logical replication of DDLs  (Joe Conway <mail@joeconway.com>)
Re: Support logical replication of DDLs  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Hello,

Here is a patch that supports replication of global object commands,
these include ROLE statements, database statements and tablespace statements.
The patch should be applied on top of the v13 DDL replication patch set that
ZJ Hou sent in the previous email.

Global objects commands are different from other DDL commands in
that:
1. Global objects commands are allowed to be executed in any databases
2. Global objects are not schema qualified
2. Global objects commands are not captured by event triggers

This patch supports global objects commands replication by WAL
logging the command using the same function for DDL logging -
LogLogicalDDLMessage, towards the end of standard_ProcessUtility.
Because global objects are not schema qualified, we can skip the deparser
invocation and directly log the original command string for replay on
the subscriber.

A key problem is global objects can get inconsistent between the
publisher and the subscriber if a command changes the global object
in a database (on the source side) which doesn't configure logical replication.
I think we can work on the following directions in order to avoid such
inconsistency:

1. Introduce a publication option for global objects command replication
and document that logical replication of global objects commands is preferred
to be configured on all databases. Otherwise inconsistency can happen
if a command changes the global object in a database which doesn't configure
logical replication.

2. Introduce database cluster level logical replication to avoid such
inconsistency,
this is especially handy when there is a large number of databases to
configure for logical
replication.

Regards,
Zheng

Вложения

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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: 回复:Re: PANIC: wrong buffer passed to visibilitymap_clear
Следующее
От: Tom Lane
Дата:
Сообщение: Re: make -C libpq check fails obscurely if tap tests are disabled