From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | maxim(dot)boguk(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18644: ALTER PUBLICATION ... SET (publish_via_partition_root) wrong/undocumented behavior. |
Date: | 2024-10-04 07:44:49 |
Message-ID: | CAA4eK1LwHnB9285-otBb2O3ez8SC4=cN1qqGee-oWp7wr4D5Sg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Oct 2, 2024 at 12:14 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
...
>
> When ALTER PUBLICATION ... SET (publish_via_partition_root) executed on the
> existing logical replication with data
> (following ALTER SUBSCRIPTION ... REFRESH PUBLICATION), the database start
> copy whole partitioned table from start (thus breaking existing logical
> replication).
> What's worse - I didn't found any way get out of such situation less than
> redo all multi-TB logical replication from blank db.
>
> Also ALTER SUBSCRIPTION ... REFRESH PUBLICATION (copy_data=false) - cannot
> be used as workaround because it lead to loose any changes in partitioned
> table between run ALTER PUBLICATION and ALTER SUBSCRIPTION.
>
> Afterthought this behavior not surprising at all but I think better to
> document it somewhere.
>
Can you tell us what additional information you want to document other
than what is already documented in CREATE PUBLICATION [1] related to
this parameter?
It would be useful if you can create a small test case to show the
exact problem and what is your usecase for the same?
[1] - https://www.postgresql.org/docs/devel/sql-createpublication.html
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2024-10-04 13:49:54 | BUG #18646: The problem with the installer |
Previous Message | neral85 | 2024-10-04 06:15:43 | AW: BUG #18615: installer cannot be executed as "nt-autorität\system" |