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