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

From Masahiko Sawada
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAD21AoAcjFxkFTf20vRXBbC_TnuVeEtgfcpU20qee4rbeA=45w@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Skipping logical replication transactions on subscriber side  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Re: Skipping logical replication transactions on subscriber side  (Greg Nancarrow <gregn4422@gmail.com>)
RE: Skipping logical replication transactions on subscriber side  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Tue, Aug 24, 2021 at 10:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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:

Thank you for the suggestion!

> >
> > 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.

+1

> 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.

Agreed.

I replaced "with commit timestamp" with "at" and rename 'commit_ts'
field name to 'ts'.

>
> 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)?

Right. I've updated the message.

Attached updated version patches. Please review them.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead
Next
From: Masahiko Sawada
Date:
Subject: Re: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION