On Thu, Jun 23, 2022 at 06:06:48PM -0700, Andres Freund wrote:
> > You are correct that we wouldn’t need to rely on the pd_flag bit to
> > determine page type for any access to a page where we come top down
> > following the hierarchy. However, for the purpose of debugging “from the
> > bottom up” it would be critical to know what type of page is being read in a
> > system with multiple page header types.
>
> That doesn't seem to justify using a bit on the page. Wouldn't it suffice to
> add such information to the BufferDesc?
The goal for the bit in pd_flags is to help identify what page header
should be present if one were to be looking at the physical page outside
of the database. One example that comes to mind is pg_upgrade. There
are other use cases where physical consistency checks could be applied,
again outside of a running database.
On Thu, Jun 23, 2022 at 04:27:33PM -0400, Robert Haas wrote:
> I think that it's not worth introducing a new page header format to
> save 10 bytes per page. Keeping things on the same format is likely to
> save more than the minor waste of space costs.
Yeah, I think we are open to both approaches, though we believe it would
be cleaner to get started with a targeted page header for the new code.
But do understand having to understand/translate/deal with two page
header types might not be worth the savings in space.
If we stick with the current page header, of course, changes to pd_flag
won't be necessary anymore.
Stepping back, it seems like folks are okay with introducing a page
header to current SLRU components and that we are leaning towards
sticking with the default one for now. We can proceed with this
approach, and if needed, change it later if more folks chime in.
Cheers.
--
Shawn Debnath
Amazon Web Services (AWS)
