Re: basebackup: add missing deflateEnd() in gzip compression sink

Thanks for reviewing, Michael.

> based on the argument of the permanent connection my take is that
> this cleanup warrants a backpatch.

Agreed. The current code leaks zlib internal state on every archive,
and on a long-lived replication connection those allocations just
pile up with no cleanup until the connection ends.

Michael Paquier <michael(at)paquier(dot)xyz> 于2026年3月20日周五 23:09写道：

> On Fri, Mar 20, 2026 at 10:02:44AM -0700, Jianghua Yang wrote:
> > While reviewing the backup compression backends, I noticed that the gzip
> > sink (basebackup_gzip.c) never calls deflateEnd(), unlike the lz4 and
> > zstd sinks which properly free their compression contexts.
> >
> > This means each archive (one per tablespace) leaks ~256KB of zlib
> > internal state until the backup's memory context is destroyed. On the
> > ERROR path, the zlib context is not released at all since there is no
> > gzip-specific cleanup callback.
>
> Yes, you are right on this one. This code could be better in cleaning
> up the resources it is working on (and note that all the other
> gzip-related code paths call the end() part if doing an init() or an
> init2()). Leaking that once per archive may not look like a big deal,
> but this is backend-side code we are talking about, and on a
> persistent replication connection it is not really cool to lose the
> context of this data with garbage coming from zlib piling up, so based
> on the argument of the permanent connection my take is that this
> cleanup warrants a backpatch.
> --
> Michael
>