From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: [PATCHES] Post-special page storage TDE support |
Date: | 2022-10-25 01:55:59 |
Message-ID: | 20221025015559.veiiktutc4zn6pyr@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Mon, Oct 24, 2022 at 12:55:53PM -0500, David Christensen wrote:
>
> Explicitly
> locking (assuming you stay in your lane) should only need to guard
> against access from other
> backends of this type if using shared buffers, so will be use-case dependent.
I'm not sure what you mean here?
> This does have a runtime overhead due to moving some offset
> calculations from compile time to
> runtime. It is thought that the utility of this feature will outweigh
> the costs here.
Have you done some benchmarking to give an idea of how much overhead we're
talking about?
> Candidates for page features include 32-bit or 64-bit checksums,
> encryption tags, or additional
> per-page metadata.
>
> While we are not currently getting rid of the pd_checksum field, this
> mechanism could be used to
> free up that 16 bits for some other purpose.
IIUC there's a hard requirement of initdb-time initialization, as there's
otherwise no guarantee that you will find enough free space in each page at
runtime. It seems like a very hard requirement for a full replacement of the
current checksum approach (even if I agree that the current implementation
limitations are far from ideal), especially since there's no technical reason
that would prevent us from dynamically enabling data-checksums without doing
all the work when the cluster is down.
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2022-10-25 02:05:10 | Re: fixing typo in comment for restriction_is_or_clause |
Previous Message | Tom Lane | 2022-10-25 00:50:24 | Re: parse partition strategy string in gram.y |