Hi, On 2026-08-28 16:06:46 -0400, Andrew Dunstan wrote: > Table AMs that store heap-format tuples on pages managed by another WAL > scheme (generic WAL, for example) can't tolerate > HeapTupleSatisfiesVisibility() and friends opportunistically writing > hint bits to the buffer: an unlogged write between two WAL operations > invalidates the before-image a later generic-WAL delta is computed > against, and standby replay ends up with a corrupt page.
Why do we care about such an AM? What's the point of all of this? I guess I could try searching the archives to look for other threads, but I shouldn't need to, to be able to judge what the point of this patch is. Increasing the code size of performance critical code can decrease performance - in almost all the cases the new branches won't be able to be optimized out, because the buffer value is not known at compile time that the values. Also, having code that has no users in tree also makes it more likely to bit-rot. Greetings, Andres Freund
