Hi Michael! Thanks for looking into this!
Attached v10 contains only the context-reuse changes, split into replay (0001) and WAL insertion (0002). The reader now owns a ZSTD_DCtx pointer under USE_ZSTD. Backend builds register a reset callback in the reader's memory context, and XLogReaderFree() unregisters it before freeing the context. I also shortened the compression-side comment. We could also avoid this cleanup bookkeeping with a static context, as in 0002. For now we only decompress independent images in one call, with no history to preserve between records. On 6 Oct 2026, at 03:34 UTC, Michael Paquier wrote: > The replay part makes the good choice, so I'm puzzled as of why you > have chosen a safe failure mode here. My reasoning was that the writer can still store an uncompressed image, whereas replay cannot restore a compressed image without the context. I changed this as you suggested, but I still think falling back to an uncompressed image is preferable. We are in a critical section. wal_compression can change during a session, so preparing the workspace outside critical sections is not straightforward. This is also the hardest and most contentious part of the whole-record and streaming compression patches. I'm trying to reuse the FPI compression buffers, but still need twice as much buffer space as before. I haven't found a better approach. Your thoughts on the allocation strategy would be very helpful, even without reviewing those patches. Thank you! Best regards, Andrey Borodin.
v10-0001-Reuse-zstd-decompression-contexts-when-restoring.patch
Description: Binary data
v10-0002-Reuse-the-zstd-context-when-compressing-WAL-imag.patch
Description: Binary data
