Re: Add the replication origin name and commit-LSN to logical replication worker errcontext - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Add the replication origin name and commit-LSN to logical replication worker errcontext
Date
Msg-id CAA4eK1+BxH3wWG_uvbq7ZpTrqtiT9jENWgwm6uMdndSeF4cvhQ@mail.gmail.com
Whole thread Raw
In response to Re: Add the replication origin name and commit-LSN to logical replication worker errcontext  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Add the replication origin name and commit-LSN to logical replication worker errcontext
List pgsql-hackers
On Wed, Mar 2, 2022 at 9:33 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Mar 2, 2022 at 12:21 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Mar 2, 2022 at 8:25 AM Peter Smith <smithpb2250@gmail.com> wrote:
> > >
> > > On Mon, Feb 28, 2022 at 11:16 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > >
> > > > The errcontext message would become like follows:
> > > >
> > > > *Before
> > > > ERROR:  duplicate key value violates unique constraint "test_pkey"
> > > > DETAIL:  Key (c)=(1) already exists.
> > > > CONTEXT:  processing remote data during "INSERT" for replication
> > > > target relation "public.test" in transaction 726 at 2022-02-28
> > > > 20:59:56.005909+09
> > > >
> > > > * After
> > > > ERROR:  duplicate key value violates unique constraint "test_pkey"
> > > > DETAIL:  Key (c)=(1) already exists.
> > > > CONTEXT:  processing remote data during "INSERT" for replication
> > > > target relation "public.test" in transaction 726 committed at LSN
> > > > 0/14BFA88 and timestamp 2022-02-28 20:58:27.964238+09 from replication
> > > > origin "pg_16395"
> > > >
> > > > I'm a bit concerned that the message may be too long.
> > >
> > > If you are willing to use abbreviations instead of full
> > > words/sentences perhaps you can shorten the long CONTEXT part like
> > > below?
> > >
> > > Before:
> > > CONTEXT:  processing remote data during "INSERT" for replication
> > > target relation "public.test" in transaction 726 committed at LSN
> > > 0/14BFA88 and timestamp 2022-02-28 20:58:27.964238+09 from
> > > replication origin "pg_16395"
> > >
> > > After:
> > > CONTEXT: processing remote data during "INSERT" for replication target
> > > relation "public.test" (txid 726, LSN 0/14BFA88, ts 2022-02-28
> > > 20:58:27.964238+09, origin "pg_16395")
> > >
> >
> > I am wondering whether we can avoid having a timestamp in the message?
> > If one wants, it can be retrieved from the errors otherwise as well.
> > For example, I see the below error in my machine:
> > 2022-02-26 07:45:25.092 IST [17644] ERROR:  duplicate key value
> > violates unique constraint "t1_pkey"
> > 2022-02-26 07:45:25.092 IST [17644] DETAIL:  Key (c1)=(1) already exists.
> > 2022-02-26 07:45:25.092 IST [17644] CONTEXT:  processing remote data
> > during "INSERT" for replication target relation "public.t1" in
> > transaction 724 at 2022-02-26 07:45:09.083848+05:30
> >
> > Now, here, won't the time at the starting of CONTEXT serves our
> > purpose. If we can remove the timestamp, I think the message won't
> > appear too long. What do you think?
>
> The time of the CONTEXT log message and the time in the message would
> largely vary when the subscriber is much behind the publisher. But I
> basically agree that the timestamp in the message might not be
> important, at least for now. If we will support conflict resolution
> that resolves based on the commit timestamp in the future, we might
> want it again.
>

Possible, but let's remove it for now as it will simplify the message
and the need for additional branches. What do you think?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Next
From: Michael Paquier
Date:
Subject: Re: pg_stat_get_replication_slot and pg_stat_get_subscription_worker incorrectly marked as proretset