Re: pg_waldump error message fix

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_waldump error message fix
Date: 2020-12-11 19:27:31
Message-ID: EDE93A86-03FE-4C9F-8DB7-34E06A6BF23C@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/10/20, 9:23 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> Please note that this is documented in xlogreader.h. Hmm. I can see
> your point here, still I think that what both of you are suggesting
> is not completely correct. For example, switching to EndRecPtr would
> cause DecodeXLogRecord() to report an error with the end of the
> current record but it makes more sense to point to ReadRecPtr in this
> case. On the other hand, it would make sense to report the beginning
> of the position we are working on when validating the header if an
> error happens at this point. So it seems to me that EndRecPtr or
> ReadRecPtr are not completely correct, and that we may need an extra
> LSN position to tell on which LSN we are working on instead that gets
> updated before the validation part, because we update ReadRecPtr and
> EndRecPtr only after this initial validation is done.

I looked through all the calls to report_invalid_record() in
xlogreader.c and noticed that all but a few in
XLogReaderValidatePageHeader() already report an LSN. Of the calls in
XLogReaderValidatePageHeader() that don't report an LSN, it looks like
most still report a position, and the remaining ones are for "WAL file
is from different database system...," which IIUC generally happens on
the first page of the segment.

Perhaps we could simply omit the LSN in the pg_waldump message.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2020-12-11 19:45:12 Re: PG vs LLVM 12 on seawasp, next round
Previous Message PegoraroF10 2020-12-11 19:06:40 anonymous block returning like a function