| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Alexey Lesovsky <lesovsky(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Skipping logical replication transactions on subscriber side |
| Date: | 2021-07-12 04:15:30 |
| Message-ID: | CAA4eK1+a8tmRwOtXEFW6pTyz2YKGq2gc_ntV_NUOmBvOXvb8bA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 12, 2021 at 9:37 AM Alexey Lesovsky <lesovsky(at)gmail(dot)com> wrote:
>
> On Mon, Jul 12, 2021 at 8:36 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> >
>> > Ok, looks nice. But I am curious how this will work in the case when there are two (or more) errors in the same subscription, but different relations?
>> >
>>
>> We can't proceed unless the first error is resolved, so there
>> shouldn't be multiple unresolved errors.
>
>
> Ok. I thought multiple errors are possible when many tables are initialized using parallel workers (with max_sync_workers_per_subscription > 1).
>
Yeah, that is possible but that covers under the second condition
mentioned by me and in such cases I think we should have separate rows
for each tablesync. Is that right, Sawada-san or do you have something
else in mind?
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2021-07-12 04:26:16 | Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values |
| Previous Message | Alexey Lesovsky | 2021-07-12 04:07:18 | Re: Skipping logical replication transactions on subscriber side |