|From:||Stephen Frost <sfrost(at)snowman(dot)net>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, "Bagga, Rishu" <bagrishu(at)amazon(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Debnath, Shawn" <sdn(at)amazon(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>|
|Subject:||Re: SLRUs in the main buffer pool - Page Header definitions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Mon, Feb 27, 2023 at 8:56 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > I'm not sure if I like that or not. I think we should clean up and
> > finish the other patches that this builds on first, and then decide if
> > we want to use the standard page header for the SLRUs or not. And if we
> > decide that we want the SLRU pages to have a page header, clean this up
> > or rewrite it from scratch.
> I'm not entirely sure either, but I think the idea has some potential.
> If SLRU pages have headers, that means that they have LSNs, and
> perhaps then we could use those LSNs to figure out when they're safe
> to write to disk, instead of ad-hoc mechanisms. See SlruSharedData's
> group_lsn field.
I agree that it's got potential and seems like the right direction to go
in. That would also allow for checksums for SLRUs and possibly support
for encryption which leverages the LSN and for a dynamic page feature
area which could allow for an extended checksum or perhaps authenticated
encryption with additonal authenticated data.
|Next Message||Jeff Davis||2023-02-27 18:25:29||Re: Non-superuser subscription owners|
|Previous Message||Tom Lane||2023-02-27 18:04:16||Re: pg_dump versus hash partitioning|