On Thu, Mar 18, 2021 at 01:46:28PM -0400, Stephen Frost wrote:
> * Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:
> > This caught my attention because a comment says "encryption does not
> > support WAL-skipped relations", but there's no direct change to the
> > definition of RelFileNodeSkippingWAL() to account for that. Perhaps I
> > am just overlooking something, since I'm just skimming anyway.
>
> This is relatively current activity and so it's entirely possible
> comments and perhaps code need further updating in this area, but to
> explain what's going on in a bit more detail-
>
> Ultimately, we need to make sure that LSNs aren't re-used. There's two
> sources of LSNs today: those for relations which are being written into
> the WAL and those for relations which are not (UNLOGGED relations,
> specifically). The 'minimal' WAL level introduces complications with
Well, the story is a little more complex than that --- we currently have
four LSN uses:
1. real LSNs for WAL-logged relfilenodes
2. real LSNs for GiST indexes for non-WAL-logged relfilenodes of permanenet relations
3. fake LSNs for GiST indexes for relfilenodes of non-permanenet relations
4. zero LSNs for non-GiST non-permanenet relations
This patch changes it so #4 gets fake LSNs, and slightly adjusts #2 & #3
so the LSNs are always unique.
> I'm not sure if it's been explicitly done yet but I believe the idea is,
> based on my last discussion with Bruce, at least initially, simply
> disallow encrypted clusters from running with wal_level=minimal to avoid
> this issue.
I adjusted the hint bit code so it potentially could work with wal_level
minimal (just for safety), but the code disallows wal_level minimal, and
is documented as such.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.