Re: Infinite loop in XLogPageRead() on standby

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: cyberdemn(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, thomas(dot)munro(at)gmail(dot)com
Subject: Re: Infinite loop in XLogPageRead() on standby
Date: 2025-01-10 05:54:16
Message-ID: Z4C2CDHMpOL3K79Y@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 01, 2024 at 01:16:37PM +0900, Kyotaro Horiguchi wrote:
> This code intends to prevent a page header error from causing a record
> reread, when a record is required to be read from multiple sources. We
> could restrict this to only fire at segment boundaries. At segment
> boundaries, we won't let LSN back up by using XLP_FIRST_IS_CONTRECORD.
>
> Having thought up to this point, I now believe that we should
> completely prevent LSN from going back in any case. One drawback is
> that the fix cannot be back-patched.

I don't immediately see why we should not be able to backpatch a fix
that restricts the early page header check to happen only at segment
boundary when we are in standby mode. Perhaps I'm just missing your
point.

If we cannot use that, wouldn't it be better just to stick with the
proposed check on the TLI and force an error in the page read callback
if the situation has changed due to a TLI jump with curFileTLI so as
we don't loop and check infinitely these incorrect pages?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-01-10 06:38:20 Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Previous Message Michael Paquier 2025-01-10 04:57:39 Re: Small refactoring around vacuum_open_relation