public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Tom Lane <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Hou, Zhijie/侯 志杰 <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Tomas Vondra <[email protected]>
Subject: Re: bogus: logical replication rows/cols combinations
Date: Tue, 24 May 2022 15:19:53 +0530
Message-ID: <CAA4eK1Kk5ZFhHR_1V-MgXYtaED74g35iGeC90ECXdDM0jGHbSw@mail.gmail.com> (raw)
In-Reply-To: <CAA4eK1KrXS0js9S0YFQRh9Vf5kaVOyz=NqA=0vMHvF1kxUJVkA@mail.gmail.com>
References: <CAA4eK1+UCfKUaf41H6zHS2qR4CZoVtZe64yx_T-JVPSb1pdw_w@mail.gmail.com>
<[email protected]>
<CAA4eK1KfL=ez5fKPB-0Nrgf7wiqN9bXP-YHHj2YH5utXAmjYug@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAA4eK1KrXS0js9S0YFQRh9Vf5kaVOyz=NqA=0vMHvF1kxUJVkA@mail.gmail.com>
On Fri, May 20, 2022 at 8:36 AM Amit Kapila <[email protected]> wrote:
>
> On Thu, May 19, 2022 at 7:54 PM Tom Lane <[email protected]> wrote:
> >
> > Justin Pryzby <[email protected]> writes:
> > > On Thu, May 19, 2022 at 10:33:13AM +0530, Amit Kapila wrote:
> > >> I have committed the first patch after fixing this part. It seems Tom
> > >> is not very happy doing this after beta-1 [1]. The reason we get this
> > >> information via this view (and underlying function) is that it
> > >> simplifies the queries on the subscriber-side as you can see in the
> > >> second patch. The query change is as below:
> > >> [1] - https://www.postgresql.org/message-id/91075.1652929852%40sss.pgh.pa.us
> >
> > > I think Tom's concern is that adding information to a view seems like adding a
> > > feature that hadn't previously been contemplated.
> > > (Catalog changes themselves are not prohibited during the beta period).
> >
> > It certainly smells like a new feature, but my concern was more around the
> > post-beta catalog change. We do those only if really forced to, and the
> > explanation in the commit message didn't satisfy me as to why it was
> > necessary. This explanation isn't much better --- if we're trying to
> > prohibit a certain class of publication definitions, what good does it do
> > to check that on the subscriber side?
> >
>
> It is required on the subscriber side because prohibition is only for
> the cases where multiple publications are combined. We disallow the
> cases where the column list is different for the same table when
> combining publications. For example:
>
> Publisher-side:
> Create table tab(c1 int, c2 int);
> Create Publication pub1 for table tab(c1);
> Create Publication pub1 for table tab(c2);
>
> Subscriber-side:
> Create Subscription sub1 Connection 'dbname=postgres' Publication pub1, pub2;
>
> We want to prohibit such cases. So, it would be better to check at the
> time of 'Create Subscription' to validate such combinations and
> prohibit them. To achieve that we extended the existing function
> pg_get_publication_tables() and view pg_publication_tables to expose
> the column list and verify such a combination. We primarily need
> column list information for this prohibition but it appeared natural
> to expose the row filter.
>
I still feel that the current approach to extend the underlying
function and view is a better idea but if you and or others are not
convinced then we can try to achieve it by extending the existing
query on the subscriber side as mentioned in my previous email [1].
Kindly let me know your opinion?
[1] - https://www.postgresql.org/message-id/CAA4eK1KfL%3Dez5fKPB-0Nrgf7wiqN9bXP-YHHj2YH5utXAmjYug%40mail.g...
--
With Regards,
Amit Kapila.
view thread (63+ 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], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: bogus: logical replication rows/cols combinations
In-Reply-To: <CAA4eK1Kk5ZFhHR_1V-MgXYtaED74g35iGeC90ECXdDM0jGHbSw@mail.gmail.com>
* 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