Re: Column Filtering in Logical Replication - Mailing list pgsql-hackers

From Rahila Syed
Subject Re: Column Filtering in Logical Replication
Date
Msg-id CAH2L28vZzcKQPV18EuwZG0wUr=E5g+E9WEbejtX-hEpjvJLLvg@mail.gmail.com
Whole thread Raw
In response to Re: Column Filtering in Logical Replication  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Column Filtering in Logical Replication  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
Hi Peter,

Hi, I was wondering if/when a subset of cols is specified then does
that mean it will be possible for the table to be replicated to a
*smaller* table at the subscriber side? 
e.g Can a table with 7 cols replicated to a table with 2 cols?

table tab1(a,b,c,d,e,f,g) --> CREATE PUBLICATION pub1 FOR TABLE
tab1(a,b)  --> table tab1(a,b)

~~

I thought maybe that should be possible, but the expected behaviour
for that scenario was not very clear to me from the thread/patch
comments. And the new TAP test uses the tab1 table created exactly the
same for pub/sub, so I couldn't tell from the test code either.
 
Currently, this capability is not included in the patch. If the table on the subscriber
server has lesser attributes than that on the publisher server, it throws an error at the 
time of CREATE SUBSCRIPTION.

About having such a functionality, I don't immediately see any issue with it as long
as we make sure replica identity columns are always present on both instances.
However, need to carefully consider situations in which a server subscribes to multiple 
publications,  each publishing a different subset of columns of a table.  
 

Thank you,
Rahila Syed

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Can a child process detect postmaster death when in pg_usleep?
Next
From: David Rowley
Date:
Subject: Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values