Re: Compression of bigger WAL records

Hi Zsolt!

On 26 Oct 2026, Zsolt Parragi wrote:
> Won't this result in a performance regression with the additional
> blocks when the header crosses multiple pages?

v12 stops nonblocking read-ahead at a split header even with free decode
space. In v13 it assembles the record and retries allocation from the
decode ring. If the ring is full, it yields without advancing
NextRecPtr.

> Shouldn't this flag be unset after decompression?

Agreed. With streams enabled, replication origin SET and DROP records
are reported as UNKNOWN. v13 clears XLR_COMPRESSED after decompression.
The new test checks both record names and that compression was used.
pg_waldump still displays physical lengths when they differ from decoded
lengths.

> And: it seems like that the patchset tries to compress incompressible
> FPI records twice (first record, then whole page, failing both times)?

I removed the second codec pass in 0001.

Thank you!

Best regards, Andrey Borodin.