Lazy allocation of pages required for verifying FPI consistency - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Lazy allocation of pages required for verifying FPI consistency
Date
Msg-id CALj2ACWenQvN0D71uE3Mu4nNk1sZOeHKg=cEONH=qnnuTX9hQQ@mail.gmail.com
Whole thread Raw
Responses Re: Lazy allocation of pages required for verifying FPI consistency
List pgsql-hackers
Hi,

Postgres verifies consistency of FPI from WAL record with the replayed
page during recovery in verifyBackupPageConsistency() when either
wal_consistency_checking for the resource manager is enabled or a WAL
record with XLR_CHECK_CONSISTENCY flag is inserted. While doing so, it
uses two intermediate pages primary_image_masked (FPI from WAL record)
and replay_image_masked (replayed page) which are dynamically
allocated (palloc'd) before the recovery starts, however, they're not
used unless verifyBackupPageConsistency() is called. And these
variables are palloc'd here for getting MAXALIGNed memory as opposed
to static char arrays. Since verifyBackupPageConsistency() gets called
conditionally only when the WAL record has the XLR_CHECK_CONSISTENCY
flag set, it's a waste of memory for these two page variables.

I propose to statically allocate these two pages using PGAlignedBlock
structure lazily in verifyBackupPageConsistency() to not waste dynamic
memory worth 2*BLCKSZ bytes. I'm attaching a small patch herewith.

Thoughts?

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Maxim Orlov
Date:
Subject: Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)
Next
From: Ashutosh Bapat
Date:
Subject: Re: Timeout when changes are filtered out by the core during logical replication