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.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/