On 12/28/25 08:49, Henson Choi wrote: > > 3. Proposal Specifications > > > 3.1 The Interface (Hook Points) > > We allow intervention by security experts through five contact points > along the I/O path: > > * *Read/Write Hooks:* |mdread_post|, |mdwrite_pre|, |mdextend_pre| > (Transformation of the data area) > * *WAL Hooks:* |xlog_insert_pre|, |xlog_decode_pre| (Transformation of > transaction logs) > > > 3.2 The Protocol Identifier (PageHeader Transformation ID) > > We allocate 5 bits of |pd_flags| to define the “Security State” of a > page. This serves as a *Status Message* sent by the security expert to > the engine, utilized for key versioning and as a migration marker. >
Isn't this rather problematic? This seems to be meant to be extensible, which means there can be multiple extensions setting the hooks. Which we generally allow, and the custom is to call the previous hook. What happens if there are multiple extensions implementing the hook? Would that be allowed or prohibited in this case? Maybe it doesn't make sense, but then why wouldn't it be possible? FWIW I find it very unlikely we'd allow reserving pd_flags bits for an extension. These bits are meant to be used by core, there's very limited number of such bits. In general, I'm somewhat skeptical of the claim a collection of hooks is "low-barrier, high-safety". It seems pretty fragile to me, and I can envision a lot of maintenance difficulties in the future. Not just for the extension developers, but for the project too - adding a bunch of random hooks is not free for us, we'll need to keep it working in future releases, etc. Perhaps the current SMGR code is not extensible/flexible enough, but then we need to improve that. I'd imagine a simple SMGR doing the encryption, but federating most of the work to a "full" SMGR. But I haven't thought about that too much. regards -- Tomas Vondra
