Reduce gunzip() peak memory to ~1x the output size

[peximus-yo]

Motivation

During an Oracle→PostgreSQL migration we stored gzipped XML documents in bytea columns and decompressed them with gunzip() in queries. Inputs of only 5–10MB compressed would intermittently get the backend killed with signal 9 and force the whole cluster through crash recovery. The root cause: text/XML routinely inflates 10–100x, and pg_gunzip() peaks at close to 3x the decompressed size — the StringInfo output buffer grows by doubling (each enlargement transiently holding old + new copies), and the finished buffer is then copied once more into a freshly palloc'd bytea. On memory-constrained deployments (cgroup limits, containers, small instances) that transient spike invokes the kernel OOM killer, which SIGKILLs the backend. The gzip.max_size guard added in v1.1.0 bounds the output, but the ~3x amplification still applies to whatever limit is configured.

Changes

Two changes bound the peak to roughly the output size itself:

• Pre-allocate from the gzip ISIZE trailer. A complete gzip stream ends with a 4-byte little-endian trailer holding the uncompressed size mod 2^32. It is attacker-controlled input, so it is used strictly as an allocation hint — clamped to gzip.max_size and MaxAllocSize — and the existing gzip.max_size enforcement inside the inflate loop is unchanged. This replaces the O(log n) enlarge-and-copy cycles with a single up-front allocation.
• Build the result bytea in place. Reserve VARHDRSZ bytes at the head of the StringInfo, stamp the varlena header at the end, and return the buffer directly — removing the final full-size copy.

Also:

• CHECK_FOR_INTERRUPTS() in the deflate/inflate loops, so large (de)compressions respond to query cancellation.
• Overflow-safe multiplication in the zlib alloc shim ((Size)items * itemsize).
• README section documenting gzip.max_size (currently undocumented) and the zip-bomb/OOM hazard.

Measurements

Peak backend RSS (log_executor_stats, fresh connection per query), PostgreSQL 17, single gunzip() call:

Decompressed output	master	this PR
100 MB	233 MB	137 MB
300 MB	648 MB	373 MB
500 MB	1.05 GB (est.)	609 MB
700 MB	—	846 MB

Reproduced end-to-end in a Docker container (postgres:17.4, --memory=1g, gzip.max_size=-1): master gets OOM-killed (server process was terminated by signal 9) from 500 MB of output onward; this branch completes up to 700 MB, md5-verified against the source files. With gzip.max_size set the failure mode is a clean cancellable ERROR in both cases — the two mechanisms are complementary.

Behavior is unchanged for multi-member streams, truncated input, and corrupted trailers (a forged ISIZE only affects the initial allocation size, never the enforced limit), and the regression suite passes as-is.