Re: Support logical replication of DDLs

From: Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Support logical replication of DDLs
Date: 2026-02-02 16:04:32
Message-ID: 080f9394-c127-4cef-865e-10f2f997125c@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message yudhi s 2026-02-02 18:39:24 Re: Top -N Query performance issue and high CPU usage
Previous Message Ron Johnson 2026-02-02 15:00:47 Re: Top -N Query performance issue and high CPU usage

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2026-02-02 16:11:32 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message Fujii Masao 2026-02-02 16:03:49 Re: Wake up backends immediately when sync standbys decrease