public inbox for pgsql-general@postgresql.org
help / color / mirror / Atom feedFrom: Vitaly Davydov <v.davydov@postgrespro.ru>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: Support logical replication of DDLs
Date: Mon, 2 Feb 2026 19:04:32 +0300
Message-ID: <080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru> (raw)
In-Reply-To: <CAA4eK1JpAcvnfOqF2DQo79pf7Cqp5=3HU5UDwBonWXW4V9ot=w@mail.gmail.com>
References: <OSZPR01MB63102C42A24D59FACF6D9CD6FD4A9@OSZPR01MB6310.jpnprd01.prod.outlook.com>
<OS3PR01MB6275328379FBE5734B4585619E54A@OS3PR01MB6275.jpnprd01.prod.outlook.com>
<ZIgf3qBvFoTsMhIc@paquier.xyz>
<CAA4eK1J8WOK9VZ9RpQRNRhRYhFOKQCu=GLCu+iBOePNO3JwLbQ@mail.gmail.com>
<ZIjmGhPWdoJUfjjE@paquier.xyz>
<CAJpy0uDaubBHyqPc1k0OysuBYDOVdoUgTWG4jXDCYj-OVSU8hg@mail.gmail.com>
<CAA4eK1+K8KMsB=+jJO6wDUSt7wF1RiXKtF-HN48nCOEOv-J-3Q@mail.gmail.com>
<CAJpy0uDLLBYAOzCePYObZ51k1epBU0hef4vbfcujKJprJVsEcQ@mail.gmail.com>
<CAJpy0uAhLjQZ0Dh0KWDFP8mrnG0rbx99_heavwn8Ke8ZuD-Umg@mail.gmail.com>
<OS0PR01MB5716A47D23EFAF988475D4A99431A@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAD21AoCXCAQ5QyXu9-xs30ViUHtUxQMmf-818d8GX--5pTmZ7g@mail.gmail.com>
<OS0PR01MB57163E6487EFF7378CB8E17C9438A@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<B38B7239-92B0-4212-A8BF-FE506C3B0F66@yandex-team.ru>
<CAA4eK1JpAcvnfOqF2DQo79pf7Cqp5=3HU5UDwBonWXW4V9ot=w@mail.gmail.com>
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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: v.davydov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Support logical replication of DDLs
In-Reply-To: <080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox