Enhanced rmgr desc routines test !has_image, not has_data

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Enhanced rmgr desc routines test !has_image, not has_data
Date: 2023-04-18 21:36:40
Message-ID: CAH2-Wzm5Sc9cBg1qWV_cEBfLNJCrW9FjS-SoHVt8FLA7Ldn8yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Recent commits that enhanced rmgr desc routines (commits 7d8219a4 and
1c453cfd) dealt with records that lack relevant block data (and so
lack anything to give a more detailed summary of) by testing
!DecodedBkpBlock.has_image -- that is the gating condition that
determines if we want to (say) output a textual array representation
of the page offset number from a given nbtree VACUUM WAL record.
Strictly speaking, this isn't the correct gating condition to test. We
should be testing the *presence* of the relevant block data instead.
Why test an inexact proxy for the condition that we care about, when
we can just as easily test the precise condition we care about
instead?

This isn't just a theoretical issue. Currently, we won't display
detailed descriptions of block data whenever wal_consistency_checking
happens to be in use. At least for those records with relevant block
data available to summarize that also happen to have an FPI that the
REDO routine isn't supposed to apply (i.e. an FPI that is included in
the record purely so that verifyBackupPageConsistency can verify that
the REDO routine produces a matching image).

Attached patch fixes this bug.

--
Peter Geoghegan

Attachment Content-Type Size
v1-0001-Test-has_data-in-rmgr-desc-routines.patch application/octet-stream 3.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2023-04-18 23:17:52 Re: Should we put command options in alphabetical order in the doc?
Previous Message Greg Stark 2023-04-18 19:53:46 Re: Request for comment on setting binary format output per session