| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | Vitaly Davydov <v(dot)davydov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Support logical replication of DDLs |
| Date: | 2026-02-09 13:40:42 |
| Message-ID: | cfca4aa4-b951-4c5a-b7d5-49018ab4fc57@proxel.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On 2/2/26 5:04 PM, Vitaly Davydov wrote:
> 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.
With this approach how do you intend to handle DDL changes which alter
data? To take a simple case we have the USING clause when altering a
column. Maybe it is a fine limitation to just not support it but I am
not convinced.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2026-02-10 01:37:21 | Fwd: JetBrains: Invoice JBAINV26114490 |
| Previous Message | Laurenz Albe | 2026-02-09 11:11:37 | Re: REFRESH MATERIALIZED VIEW CONCURRENTLY is blocking autovacuum on table |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-02-09 13:40:48 | Re: Add 64-bit XIDs into PostgreSQL 15 |
| Previous Message | Madyshev Egor | 2026-02-09 13:19:45 | RE: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY) |