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 <[email protected]> 于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 >
