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
(Masahiko Sawada <sawada.mshk@gmail.com>)
|
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: