Re: Column Filtering in Logical Replication

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Column Filtering in Logical Replication
Date: 2021-12-14 16:43:48
Message-ID: 202112141643.xerpcvfpi7bs@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Dec-13, Alvaro Herrera wrote:

> I think this means we need a new OBJECT_PUBLICATION_REL_COLUMN value in
> the ObjectType (paralelling OBJECT_COLUMN), and no new ObjectClass
> value. Looking now to confirm.

After working on this a little bit more, I realized that this is a bad
idea overall. It causes lots of complications and it's just not worth
it. So I'm back at my original thought that we need to throw an ERROR
at ALTER TABLE .. DROP COLUMN time if the column is part of a
replication column filter, and suggest the user to remove the column
from the filter first and reattempt the DROP COLUMN.

This means that we need to support changing the column list of a table
in a publication. I'm looking at implementing some form of ALTER
PUBLICATION for that.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-12-14 16:59:50 Re: O(n) tasks cause lengthy startups and checkpoints
Previous Message Mark Dilger 2021-12-14 15:41:25 Re: Commitfest 2021-11 Patch Triage - Part 3