Re: pg_get_publication_tables() output duplicate relid - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_get_publication_tables() output duplicate relid
Date
Msg-id CAA4eK1+FD=MjM6ecaNsFduNZuLAbm1odYwM9A9re21TG-aGTrw@mail.gmail.com
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: pg_get_publication_tables() output duplicate relid
List pgsql-hackers
On Wed, Nov 24, 2021 at 12:02 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Tue, Nov 23, 2021 at 12:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Isn't it better to document this case and explain what
> > users can expect instead of trying to design a solution around this?
>
> I thought about the problems you've described and it looks like I
> hadn't considered many of the details which complicate implementing a
> solution for this.
>
> So yeah, documenting the ATTACH issue as a limitation sounds like the
> best course for now.  I might word it as follows and add it under
> Notes at https://www.postgresql.org/docs/current/sql-createpublication.html:
>
> "ATTACHing a table into a partition tree whose root is published using
> a publication with publish_via_partition_root set to true does not
> result in the table's existing contents to be replicated."
>

Instead of "to be", shall we use "being"?

> I'm not sure there's a clean enough workaround to this that we can add
> to the paragraph.
>
> Does that make sense?
>

Yeah, that sounds reasonable. I think the case with
"publish_via_partition_root = false" should work but please test it
once. The other thing which we need to consider about all these fixes
is whether to back patch them or not. I think it is on case to case
basis. I feel this limitation should be documented and backpatched,
what do you think? Feel free to submit patches accordingly.

> > Even if we do so the streaming after attach partition problem as
> > discussed above should be fixed.
>
> I agree.  I have reproduced the problem though haven't managed to pin
> down the cause yet.
>

No problem, do let us know whatever be your findings at the end. I
think now we know how to proceed with this attach issue, maybe we
should also try to commit the fixes for other issues.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Post-CVE Wishlist
Next
From: Amit Kapila
Date:
Subject: Re: pg_get_publication_tables() output duplicate relid