Re: Moving forward with TDE [PATCH v3] - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: Moving forward with TDE [PATCH v3] |
Date | |
Msg-id | ZUj+pfXH+aNgTHIu@tamriel.snowman.net Whole thread Raw |
In response to | Re: Moving forward with TDE [PATCH v3] (Andres Freund <andres@anarazel.de>) |
Responses |
Re: Moving forward with TDE [PATCH v3]
Re: Moving forward with TDE [PATCH v3] |
List | pgsql-hackers |
Greetings, Thanks for your feedback on this. * Andres Freund (andres@anarazel.de) wrote: > I still am quite quite unconvinced that using the LSN as a nonce is a good > design decision. This is a really important part of the overall path to moving this forward, so I wanted to jump to it and have a specific discussion around this. I agree that there are downsides to using the LSN, some of which we could possibly address (eg: include the timeline ID in the IV), but others that would be harder to deal with. The question then is- what's the alternative? One approach would be to change the page format to include space for an explicit nonce. I don't see the community accepting such a new page format as the only format we support though as that would mean no pg_upgrade support along with wasted space if TDE isn't being used. Ideally, we'd instead be able to support multiple page formats where users could decide when they create their cluster what features they want- and luckily we even have such an effort underway with patches posted for review [1]. Certainly, with the base page-special-feature patch, we could have an option for users to choose that they want a better nonce than the LSN, or we could bundle that assumption in with, say, the authenticated-encryption feature (if you want authenticated encryption, then you want more from the encryption system than the basics, and therefore we presume you also want a better nonce than the LSN). Another approach would be a separate fork, but that then has a number of downsides too- every write has to touch that too, and a single page of nonces would cover a pretty large number of pages also. Ultimately, I agree with you that the LSN isn't perfect and we really shouldn't be calling it 'ideal' as it isn't, and we can work to fix that language in the patch, but the lack of any alternative being proposed that might be acceptable makes this feel a bit like rock management [2]. My apologies if there's something good that's already been specifically pushed and I just missed it; if so, a link to that suggestion and discussion would be greatly appreciated. Thanks again! Stephen [1]: https://commitfest.postgresql.org/45/3986/ [2]: https://en.wikipedia.org/wiki/Wikipedia:Bring_me_a_rock ; though that isn't great for a quick summary (which I tried to find on an isolated page somewhere and didn't). The gist is, without a suggestion of things to try, we're left to our own devices to try and figure out things which might be successful, only to have those turned down too when we come back with them, see [1] for what feels like an example of this. Given your feedback overall, which I'm very thankful for, I'm hopeful that you see that this is, indeed, a useful feature that people are asking for and therefore are willing to spend some time on it, but if the feedback is that nothing on the page is acceptable to use for the nonce, we can't put the nonce somewhere else, and we can't change the page format, then everything else is just moving deck chairs around on the titanic that has been this effort.
Attachment
pgsql-hackers by date: