From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_waldump error message fix |
Date: | 2020-12-14 17:20:34 |
Message-ID: | F8E394B7-13D4-46A9-86AB-4C8365525EB3@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/13/20, 7:01 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> On Mon, Dec 14, 2020 at 10:26:01AM +0900, Kyotaro Horiguchi wrote:
>> Yeah, I had the same feeling. At least, the two LSNs in the message
>> under discussion are simply redundant. So +1 to just remove the LSN at
>> the caller site.
>
> That would mean that we are ready to accept that we will never forget
> to a LSN in any of the messages produced by xlogreader.c or any of the
> callbacks used by pg_waldump. FWIW, I'd rather let a position in this
> report than none. At least it allows users to know the area where the
> problem happened.
Yeah. Unfortunately, I suspect we will have the same problem if we
add a new variable that we only use to track the LSN to report for
errors.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-12-14 17:30:47 | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit |
Previous Message | Fujii Masao | 2020-12-14 17:00:21 | Re: Add Information during standby recovery conflicts |