public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
To: Rahila Syed <[email protected]>
To: Peter Smith <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Column Filtering in Logical Replication
Date: Mon, 12 Jul 2021 14:42:55 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAH2L28vZzcKQPV18EuwZG0wUr=E5g+E9WEbejtX-hEpjvJLLvg@mail.gmail.com>
References: <CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com>
<CAHut+PuP_hXzJQtLOvyaCxEPySPqhFheO2gZA3RcugMMfz3RSQ@mail.gmail.com>
<CAH2L28vZzcKQPV18EuwZG0wUr=E5g+E9WEbejtX-hEpjvJLLvg@mail.gmail.com>
On 7/12/21 10:32 AM, Rahila Syed wrote:
> 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.
>
That's a bit surprising, to be honest. I do understand the patch simply
treats the filtered columns as "unchanged" because that's the simplest
way to filter the *data* of the columns. But if someone told me we can
"filter columns" I'd expect this to work without the columns on the
subscriber.
> 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.
Yeah, that seems like an inherent requirement.
> However, need to carefully consider situations in which a server
> subscribes to multiple
> publications, each publishing a different subset of columns of a table.
>
Isn't that pretty much the same situation as for multiple subscriptions
each with a different set of I/U/D operations? IIRC we simply merge
those, so why not to do the same thing here and merge the attributes?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
view thread (167+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Column Filtering in Logical Replication
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox