Re: Support logical replication of DDLs
| От | Vitaly Davydov |
|---|---|
| Тема | Re: Support logical replication of DDLs |
| Дата | |
| Msg-id | 080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru обсуждение исходный текст |
| Ответ на | Re: Support logical replication of DDLs (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Support logical replication of DDLs
|
| Список | pgsql-hackers |
Dear Hackers, I see, that the primary idea in this thread is to capture DDL statements with the use of the utility hook, convert it into a json-like format, save it in the WAL (xl_logical_message) and send it to a peer using the logical replication subsystem (walsender). This approach has a major challenge that was already highlighted: DDL statements may be too complex to convert it into a json string (for example, unlogged/temporary objects in DDL statements). An alternative approach, that was highlighted in the discussion by Dilip Kumar is to decode system catalog changes. It helps to deal with complex DDL statements containing temp objects and to work with a final representation of changes stored in the WAL. Personally, I like this approach. I would share the following idea: 1. Log into the WAL system catalog changes (tuples) suitable for logical decoding (introduce a new wal_level = logical_ddl). I think, not all system catalog changes are needed for decoding (not sure, we have to decode pg_depend changes). 2. Implement a decoder of system catalog changes, that can produce a parse tree using existing structures from parsenodes.h. 3. Based on the decoded parse tree, we can convert it into json or DDL SQL statements in the output plugin. ParseTree to DDL SQL converter can be built-in into the core. Output plugin can decide which converter to use. DDL sql can be directly applied on the replica. 4. Another option is to create json/ddl-sql from system catalog changes without an intermediate representation, but, anyway, when we interpret system catalog changes we have to temporary save current data in some structures. Parsenodes is the already existing solution for it. The open question: can we unambiguously decode system catalog changes? I would appreciate any feedback. With best regards, Vitaly
В списке pgsql-hackers по дате отправления: