From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Add more error context to RestoreBlockImage() and consume it |
Date: | 2022-09-09 01:02:07 |
Message-ID: | E1oWSPH-0024dJ-1A@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Add more error context to RestoreBlockImage() and consume it
On failure in restoring a block image, no details were provided, while
it is possible to see failure with an inconsistent record state, a
failure in processing decompression or a failure in decompression
because a build does not support this option.
RestoreBlockImage() is used in two code paths in the backend code,
during recovery and when checking a page consistency after applying
masking, and both places are changed to consume the error message
produced by the internal routine when it returns a false status. All
the error messages are reported under ERRCODE_INTERNAL_ERROR, that gets
used also when attempting to access a page compressed by a method
not supported by the build attempting the decompression. This is
something that can happen in core when doing physical replication with
primary and standby using inconsistent build options, for example.
This routine is available since 2c03216d and it has never provided any
context about the error happening when it failed. This change is
justified even more after 57aa5b2, that introduced compression of FPWs
in WAL.
Reported-by: Justin Prysby
Author: Michael Paquier
Discussion: https://postgr.es/m/20220905002320.GD31833@telsasoft.com
Backpatch-through: 15
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/0a7c9ee50062e0f48cdd89b9c0e166ff59caabc8
Modified Files
--------------
src/backend/access/transam/xlogreader.c | 22 +++++++++++++++++-----
src/backend/access/transam/xlogrecovery.c | 4 +++-
src/backend/access/transam/xlogutils.c | 4 +++-
3 files changed, 23 insertions(+), 7 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-09-09 01:03:04 | Re: pgsql: Raise a warning if there is a possibility of data from multiple |
Previous Message | Andrew Dunstan | 2022-09-08 20:32:14 | Re: pgsql: Fix perltidy breaking perlcritic |