Re: Lazy allocation of pages required for verifying FPI consistency

At Thu, 12 Jan 2023 15:02:25 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)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