| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add into REFRESH PUBLICATION parameter exception_behaviour |
| Date: | 2026-02-17 08:09:30 |
| Message-ID: | 6c2a0f05-196b-4bcb-b0f8-a7e69cd71a37@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 17/2/26 06:11, Amit Kapila wrote:
> On Tue, Feb 17, 2026 at 9:52 AM Andrei Lepikhov <lepihov(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kirill Reshke | 2026-02-17 08:17:17 | Re: Document How Commit Handles Aborted Transactions |
| Previous Message | Andreas Karlsson | 2026-02-17 08:09:05 | Improve pgindent's formatting named fields in struct literals and varidic functions |