| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Optionally automatically disable logical replication subscriptions on error |
| Date: | 2021-06-21 04:54:53 |
| Message-ID: | 14738A39-8000-463E-A0BA-6729930A32DA@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jun 20, 2021, at 8:09 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> Because currently, we don't proceed after an error unless it is
> resolved. Why do you think there could be multiple such transactions?
Just as one example, if the subscriber has a unique index that the publisher lacks, any number of transactions could add non-unique data that then fails to apply on the subscriber. My patch took the view that the user should figure out how to get the subscriber side consistent with the publisher side, but if you instead take the approach that problematic commits should be skipped, it would seem that arbitrarily many such transactions could be committed on the publisher side.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-06-21 04:56:38 | Re: [bug?] Missed parallel safety checks, and wrong parallel safety |
| Previous Message | Sandeep Thakkar | 2021-06-21 04:32:44 | Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX. |