Horton
Menu

Re: Support logical replication of DDLs

Vitaly Davydov <v.davydov@postgrespro.ru>

View thread
From: Vitaly Davydov <v.davydov@postgrespro.ru>
To: pgsql-hackers@lists.postgresql.org
Date: 2026-02-02T16:04:32Z
Lists: pgsql-hackers, pgsql-general 
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add a run_as_owner option to subscriptions.

  2. Refactor pgoutput_change().

  3. Print the correct aliases for DML target tables in ruleutils.

  4. Fix object identity string for transforms

  5. Add grantable MAINTAIN privilege and pg_maintain role.

  6. Get rid of recursion-marker values in enum AlterTableType

  7. Release cache tuple when no longer needed

  8. Empty search_path in logical replication apply worker and walsender.

  9. Refactor format_type APIs to be more modular

  10. Use wrappers of PG_DETOAST_DATUM_PACKED() more.