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

From Kyotaro Horiguchi
Subject Re: Lazy allocation of pages required for verifying FPI consistency
Date
Msg-id 20230116.105243.2235508833456771119.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Lazy allocation of pages required for verifying FPI consistency  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Lazy allocation of pages required for verifying FPI consistency
List pgsql-hackers
At Thu, 12 Jan 2023 15:02:25 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in 
> On the contrary, PGAlignedBlock is being used elsewhere in the code;

I noticed it and had the same feeling, and thought that they don't
justify to do the same at other places.

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

Right. So we could allocate them at the first use as below, but...

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

Yeah, we could do that. But as I mentioned before, that happens only
on startup thus it can be said that that's not worth bothering.  On
the other hand I don't think it's great to waste 16kB * max_backends
memory especially when it is clearly recognized and easily avoidable.

I guess the reason for the code is more or less that.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication
Next
From: Michael Paquier
Date:
Subject: Re: constify arguments of copy_file() and copydir()