Re: Skipping logical replication transactions on subscriber side

Поиск
Список
Период
Сортировка
От Greg Nancarrow
Тема Re: Skipping logical replication transactions on subscriber side
Дата
Msg-id CAJcOf-ch1Ti28dBu=--JFToymK7bNbanFtx+9UfmFOvaddhuxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Skipping logical replication transactions on subscriber side  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Skipping logical replication transactions on subscriber side
Список pgsql-hackers
On Tue, Oct 26, 2021 at 5:16 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> I agree that we will need a separate syntax for conflict resolution
> but there is some similarity in what I proposed above (On
> Error/Conflict [1]) with the existing syntax of Insert ... On
> Conflict. I understand that here the context is different and we are
> storing this information in the catalog but still there is some syntax
> similarity and it will avoid adding new syntax variants.
>

The problem I see with the suggested syntax:

Alter Subscription <sub_name> On Error ( subscription_parameter [=
value] [, ... ] );
OR
Alter Subscription <sub_name> On Conflict ( subscription_parameter [=
value] [, ... ] );

is that "On Error ..." and "On Conflict" imply an action to be done on
a future condition (Error/Conflict), whereas at least in this case
(skip_xid) it's only AFTER the problem condition has occurred that we
know the XID of the failed transaction that we want to skip. So that
syntax looks a little confusing to me. Unless you had something else
in mind on how it would work?

Regards,
Greg Nancarrow
Fujitsu Australia



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [PATCH] Fix memory corruption in pg_shdepend.c
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Gather performance analysis