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-17 15:58:50
Message-ID: 202112171558.klt66al2w5yg@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021-Dec-17, Rahila Syed wrote:

> > 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.
>
> I think right now the patch contains support only for ALTER
> PUBLICATION.. ADD TABLE with column filters. In order to achieve
> changing the column lists of a published table, I think we can extend
> the ALTER TABLE ..SET TABLE syntax to support specification of column
> list.

Yeah, that's what I was thinking too.

> > So this whole thing can be reduced to just this:
>
> > if (att_map != NULL && !bms_is_member(att->attnum, att_map))
> > continue; /* that is, don't send this attribute */
>
> I agree the condition can be shortened now. The long if condition was
> included because initially the feature allowed specifying filters
> without replica identity columns(sent those columns internally without
> user having to specify).

Ah, true, I had forgotten that. Thanks.

> > 900 + * the table is partitioned. Run a recursive query to iterate through all
> > 901 + * the parents of the partition and retreive the record for the parent
> > 902 + * that exists in pg_publication_rel.
> > 903 + */
>
> The above comment in fetch_remote_table_info() can be changed as the
> recursive query is no longer used.

Oh, of course.

I'll finish some loose ends and submit a v10, but it's still not final.

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"Right now the sectors on the hard disk run clockwise, but I heard a rumor that
you can squeeze 0.2% more throughput by running them counterclockwise.
It's worth the effort. Recommended." (Gerry Pourwelle)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-12-17 17:21:13 Re: pg_upgrade should truncate/remove its logs before running
Previous Message Justin Pryzby 2021-12-17 15:43:56 \d with triggers: more than one row returned by a subquery used as an expression