Re: [PATCHES] Post-special page storage TDE support
От
Julien Rouhaud
Тема
Re: [PATCHES] Post-special page storage TDE support
Дата
Msg-id
20221025015559.veiiktutc4zn6pyr@jrouhaud
Ответ на
[PATCHES] Post-special page storage TDE support (David Christensen)
Список
Дерево обсуждения
[PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Julien Rouhaud <rjuju123@gmail.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Andres Freund <andres@anarazel.de>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Aleksander Alekseev <aleksander@timescale.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Greg Sabino Mullane <htamfids@gmail.com>
Re: [PATCHES] Post-special page storage TDE support Stephen Frost <sfrost@snowman.net>
Re: [PATCHES] Post-special page storage TDE support Peter Geoghegan <pg@bowt.ie>
Re: [PATCHES] Post-special page storage TDE support Andres Freund <andres@anarazel.de>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Andres Freund <andres@anarazel.de>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Stephen Frost <sfrost@snowman.net>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
Re: [PATCHES] Post-special page storage TDE support Stephen Frost <sfrost@snowman.net>
Re: [PATCHES] Post-special page storage TDE support Stephen Frost <sfrost@snowman.net>
Re: [PATCHES] Post-special page storage TDE support David Christensen <david.christensen@crunchydata.com>
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.
В списке pgsql-hackers по дате отправления