Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAA4eK1J2MH4WDfcwn_e=Qc=djoesGSO9DAupiaLQFuMFBhAz+Q@mail.gmail.com
Whole thread Raw
In response to RE: Skipping logical replication transactions on subscriber side  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Responses Re: Skipping logical replication transactions on subscriber side  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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 by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: Failure of subscription tests with topminnow
Next
From: Amit Kapila
Date:
Subject: Re: Failure of subscription tests with topminnow