On Thu, Dec 2, 2021 at 9:44 houzj.f...@fujitsu.com <houzj.f...@fujitsu.com> wrote: > On Wed, Dec 1, 2021 3:01 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Mon, Nov 22, 2021 at 12:55 PM Amit Langote > > > > <amitlangot...@gmail.com> wrote: > > > > > On second thought, I agree that de-duplicating partitions from > > > > > this view is an improvement. > > > > > > > > Fair enough. Hou-San, Can you please submit the updated patch after > > > > fixing any pending comments including the test case? > > > > > > Attach the updated patch which address the comments so far. > > > > > > The patch only adds a testcase in publication.sql because the > > > duplicate output doesn't cause unexpected behavior in pub-sub test. > > > > Thanks, the patch looks good to me. I have slightly changed the commit > > message in the attached. I would like to commit this only in HEAD as there > > is no > > user complaint about this and it might not stop any user's service unless > > it relies > > on this view's output for the initial table synchronization.
The patch looks good to me too in that it gets the job done. Reading Alvaro's email at the top again gave me a pause to reconsider what I had said in reply. It might indeed have been nice if the publication DDL itself had prevented the cases where a partition and its ancestor are added to a publication, though as Hou-san mentioned, partition ATTACHes make that a bit tricky to enforce at all times, though of course not impossible. Maybe it's okay to just de-duplicate pg_publication_tables output as the patch does, even though it may appear to be a band-aid solution if we one considers Alvaro's point about consistency. Sorry about too many second thoughts on these threads. :( > > What do you think? > I agreed that we can commit only in HEAD. +1 to do this only in HEAD. Thank you. -- Amit Langote EDB: http://www.enterprisedb.com
