On Fri, Apr 3, 2026 at 1:11 PM Tom Lane <[email protected]> wrote: > In any case, this is all completely moot if we don't write code to > de-sparse a sparse entry: we will not be able to validate WAL data > if the WAL file is missing some pages. So I see little point in > having code that tolerates pax headers if it doesn't also do that.
Yeah. FWIW I spent a few hours hacking on that the other day and could decode many files, but I now realise that the task was made more difficult by a problem you fixed: without header validation, small mistakes resulted in corruption or went bananas. With that now addressed, I hope I can get it into shape and propose it for the next cycle... For what it's worth, I was just speculating about how one might reasonably handle unrecognised *non-standard* header names, not the POSIX-standardised ones which, you're right, we'd probably need to grok properly. If we assumed reasonable engineering decisions following (what I understood to be) the spirit of pax, maybe we could assume that new non-standard headers either don't affect file contents and thus could be ignored (think: GNU.windows.permissions=...), or do affect file contents but have measures in place to prevent unknown encodings from being exposed to unsuspecting software (think: deathstation.byte=9bit). That's a position we could choose to take, anyway, in the absence of a crystal ball... Fortunately there aren't really many implementations of POSIX left, so it's not like we're dealing with the Fermi Paradox here...
