Re: Skipping logical replication transactions on subscriber side

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Skipping logical replication transactions on subscriber side
Дата
Msg-id CAA4eK1J2MH4WDfcwn_e=Qc=djoesGSO9DAupiaLQFuMFBhAz+Q@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Skipping logical replication transactions on subscriber side  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Ответы Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Tue, Aug 24, 2021 at 11:44 AM tanghy.fnst@fujitsu.com
<tanghy.fnst@fujitsu.com> wrote:
>
> On Monday, August 23, 2021 11:09 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > I've attached updated patches. Please review them.
> >
>
> I tested v10-0001 patch in both streaming and no-streaming more. All tests works well.
>
> I also tried two-phase commit feature, the error context was set as expected,
> but please allow me to propose a fix suggestion on the error description:
>
> CONTEXT:  processing remote data during "INSERT" for replication target relation
> "public.test" in transaction 714 with commit timestamp 2021-08-24
> 13:20:22.480532+08
>
> It said "commit timestamp", but for 2pc feature, the timestamp could be "prepare timestamp" or "rollback timestamp",
too.
> Could we make some change to make the error log more comprehensive?
>

I think we can write something like: (processing remote data during
"INSERT" for replication target relation "public.test" in transaction
714 at 2021-08-24 13:20:22.480532+08). Basically replacing "with
commit timestamp" with "at". This is similar to what we do
test_decoding module for transaction timestamp. The other idea could
be we print the exact operation like commit/prepare/rollback which is
also possible because we have that information while setting context
info but that might add a bit more complexity which I don't think is
worth it.

One more point about the  v10-0001* patch: From the commit message
"Add logical changes details to errcontext of apply worker errors.",
it appears that the context will be added only for the apply worker
but won't it get added for tablesync worker as well during its sync
phase (when it tries to catch up with apply worker)?

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Ajin Cherian
Дата:
Сообщение: Re: Failure of subscription tests with topminnow
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Failure of subscription tests with topminnow