Re: BUG #18644: ALTER PUBLICATION ... SET (publish_via_partition_root) wrong/undocumented behavior.
От | Amit Kapila |
---|---|
Тема | Re: BUG #18644: ALTER PUBLICATION ... SET (publish_via_partition_root) wrong/undocumented behavior. |
Дата | |
Msg-id | CAA4eK1LwHnB9285-otBb2O3ez8SC4=cN1qqGee-oWp7wr4D5Sg@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #18644: ALTER PUBLICATION ... SET (publish_via_partition_root) wrong/undocumented behavior. (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18644: ALTER PUBLICATION ... SET (publish_via_partition_root) wrong/undocumented behavior.
|
Список | pgsql-bugs |
On Wed, Oct 2, 2024 at 12:14 AM PG Bug reporting form <noreply@postgresql.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.
В списке pgsql-bugs по дате отправления: