Re: Various bugs if segment containing redo pointer does not exist
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>, Michael Paquier <michael.paquier@gmail.com>,
Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2023-10-24T12:58:04Z
Lists: pgsql-hackers
On Mon, Oct 23, 2023 at 8:43 PM Andres Freund <andres@anarazel.de> wrote: > The source of the emode=13=DEBUG2 is that that's hardcoded in > WaitForWALToBecomeAvailable(). I guess the error ought to come from > XLogPageRead(), but all that happens is this: > > case XLREAD_FAIL: > if (readFile >= 0) > close(readFile); > readFile = -1; > readLen = 0; > readSource = XLOG_FROM_ANY; > return XLREAD_FAIL; I've been under the impression that the guiding principle here is that we shouldn't error out upon hitting a condition that should only cause us to switch sources. I think WaitForWALToBecomeAvailable() is supposed to set things up so that XLogPageRead()'s call to pg_pread() will succeed. If it says it can't, then XLogPageRead() is only obliged to pass that information up to the caller, who can decide to wait longer for the data to show up, or give up, or whatever it wants to do. On the other hand, if WaitForWALToBecomeAvailable() says that it's fine to go ahead and call pg_pread() and pg_pread() then fails, then that means that we've got a problem with the WAL file other than it just not being available yet, like it's the wrong length or there was an I/O error, and those are reportable errors. Said differently, in the former case, the WAL is not broken, merely not currently available; in the latter case, it's broken. The legibility and maintainability of this code are certainly not great. The xlogreader mechanism is extremely useful, but maybe we should have done more cleanup of the underlying mechanism first. It's a giant ball of spaghetti code that is challenging to understand and almost impossible to validate thoroughly (as you just discovered). -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Fail recovery when missing redo checkpoint record without backup_label
- 14161bca40a0 14.21 landed
- 95ef6f4904a5 15.16 landed
- 1aa57e9ed548 16.12 landed
- f5927da4ff6c 17.8 landed
- 68ebdf2b07f6 18.2 landed
- dc7c77f825d7 19 (unreleased) landed
-
If recovery.conf is created after "pg_ctl stop -m i", do crash recovery.
- abf5c5c9a4f1 9.3.0 cited