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 по дате отправления: