On Thu, Mar 18, 2021 at 01:46:28PM -0400, Stephen Frost wrote: > * Alvaro Herrera (alvhe...@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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
