Re: Skipping logical replication transactions on subscriber side

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Skipping logical replication transactions on subscriber side
Дата
Msg-id CAA4eK1+a8tmRwOtXEFW6pTyz2YKGq2gc_ntV_NUOmBvOXvb8bA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Skipping logical replication transactions on subscriber side  (Alexey Lesovsky <lesovsky@gmail.com>)
Ответы Re: Skipping logical replication transactions on subscriber side
Список pgsql-hackers
On Mon, Jul 12, 2021 at 9:37 AM Alexey Lesovsky <lesovsky@gmail.com> wrote:
>
> On Mon, Jul 12, 2021 at 8:36 AM Amit Kapila <amit.kapila16@gmail.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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexey Lesovsky
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: David Rowley
Дата:
Сообщение: Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values