Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2021-Mar-18, Stephen Frost wrote: > > > * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > > > Patch 10 uses the term "WAL-skip relations". What does that mean? Is > > > it "relations that are not WAL-logged"? I suppose we already have a > > > term for this; I'm not sure it's a good idea to invent a different term > > > that is only used in this new place. > > > > This is discussed in src/backend/access/transam/README, specifically the > > section that talks about Skipping WAL for New RelFileNode. Basically, > > it's the 'wal_level=minimal' optimization which allows WAL to be > > skipped. > > Hmm ... that talks about WAL-skipping *changes*, not WAL-skipping > *relations*. I thought WAL-skipping meant unlogged relations, but > I understand now that that's unrelated. In the transam/README, WAL-skip > means a change in a transaction in a relfilenode that, if rolled back, > would disappear; and I'm not sure I understand how the code is handling > the case that a relation is under that condition. > > 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 this requirement because tables created (or truncated) inside a transaction are considered permanent once they're committed, but the data pages in those relations don't go into the WAL and the LSNs on the pages of those relations isn't guaranteed to be either unique or even necessarily set, and if we were to generate LSNs for those it would be required to be done by actually advancing the WAL LSN, which would require writing into the WAL and therefore wouldn't be quite the optimization that's expected. 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. Thanks, Stephen
signature.asc
Description: PGP signature