From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | bharath(dot)rupireddyforpostgres(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Remove an unnecessary LSN calculation while validating WAL page header |
Date: | 2022-10-11 09:49:36 |
Message-ID: | CAMbWs4_rEJ67WPiELY+dwGa=-XWbN44Gko2PbQi7XvsEoAHNGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 11, 2022 at 1:44 PM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
wrote:
> At Mon, 10 Oct 2022 08:53:55 +0530, Bharath Rupireddy <
> bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > It looks like we have an unnecessary XLogSegNoOffsetToRecPtr() in
> > XLogReaderValidatePageHeader(). We pass the start LSN of the WAL page
> > and check if it matches with the LSN that was stored in the WAL page
> > header (xlp_pageaddr). We find segno, offset and LSN again using
> > XLogSegNoOffsetToRecPtr(). This happens to be the same as the passed
> > in LSN 'recptr'.
>
> Yeah, that's obviously useless. It looks like a thinko in pg93 when
> recptr became to be directly passed from the caller instead of
> calculating from static variables for file, segment and in-segment
> offset.
+1. This should be introduced in 7fcbf6a4 as a thinko. A grep search
shows other callers of XLogSegNoOffsetToRecPtr have no such issue.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2022-10-11 10:05:01 | Re: Is there any plan to support online schem change in postgresql? |
Previous Message | jiye | 2022-10-11 09:43:03 | Is there any plan to support online schem change in postgresql? |