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
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 |