Re: Add into REFRESH PUBLICATION parameter exception_behaviour
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: Add into REFRESH PUBLICATION parameter exception_behaviour |
| Дата | |
| Msg-id | 6c2a0f05-196b-4bcb-b0f8-a7e69cd71a37@gmail.com обсуждение исходный текст |
| Ответ на | Re: Add into REFRESH PUBLICATION parameter exception_behaviour (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Add into REFRESH PUBLICATION parameter exception_behaviour
|
| Список | pgsql-hackers |
On 17/2/26 06:11, Amit Kapila wrote: > On Tue, Feb 17, 2026 at 9:52 AM Andrei Lepikhov <lepihov@gmail.com> wrote: > If we introduce a new state like FAIL for a table, then in that state > apply_worker should skip the new updates for that table (see > should_apply_changes_for_rel()) till the copy is successful. So, all > other changes in future transactions will keep getting applied except > for tables that have failed status. I think this could lead to > inconsistency while replicating data. Thanks for your answer, but I still don't get the idea. The case I am talking about is the following: In the absence of DDL propagation, it is a good palliative to DROP a table from publication, perform the necessary ALTER TABLEs on both sides, and ADD the table back to the publication. I only proposed that if the REFRESH PUBLICATION that re-introduced such a table fails, complain and remove it from the subscription, as if you had never executed the 'REFRESH PUBLICATION' command. Where is the inconsistency? -- regards, Andrei Lepikhov, pgEdge
В списке pgsql-hackers по дате отправления: