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

From Bharath Rupireddy
Subject Re: Lazy allocation of pages required for verifying FPI consistency
Date
Msg-id CALj2ACW_3wr0Dby9oJBe7qYpGpSsu4DvY3s2hNtXbrZVRXLRjg@mail.gmail.com
Whole thread Raw
In response to Re: Lazy allocation of pages required for verifying FPI consistency  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Lazy allocation of pages required for verifying FPI consistency
List pgsql-hackers
On Thu, Jan 12, 2023 at 1:59 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Mon, 9 Jan 2023 20:00:00 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in
> > 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?
>
> IMHO, it's a bit scaring to me to push down the execution stack by
> that large size. I tend to choose the (current) possible memory
> wasting only on startup process than digging stack deeply.

On the contrary, PGAlignedBlock is being used elsewhere in the code;
some of them are hot paths. verifyBackupPageConsistency() is not
something that gets called always i.e. WAL consistency checks are done
conditionally - when either one enables wal_consistency_checking for
the rmgr or the WAL record is flagged with
XLR_CHECK_CONSISTENCY (core doesn't do, it's an external module, if
any, do that).

I really don't see much of a problem in allocating them statically and
pushing closer to where they're being used. If this really concerns,
at the least, the dynamic allocation needs to be pushed to
verifyBackupPageConsistency() IMO with if (first_time) { allocate two
blocks with palloc} and use them. This at least saves some memory on
the heap for most of the servers out there.

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



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Named Operators
Next
From: "Drouvot, Bertrand"
Date:
Subject: Remove nonmeaningful prefixes in PgStat_* fields