public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jianghua Yang <[email protected]>
To: Michael Paquier <[email protected]>
Cc: [email protected]
Subject: Re: basebackup: add missing deflateEnd() in gzip compression sink
Date: Sat, 21 Mar 2026 06:09:46 -0700
Message-ID: <CAAZLFmQeS4AFC6mNQNhyZWGUMXEkOmQA11UL28N-6c=CYtqnoA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAAZLFmQNJ0QNArpWEOZXwv=vbumcWKEHz-b1me5gBqRqG67EwQ@mail.gmail.com>
	<[email protected]>

  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
>

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: basebackup: add missing deflateEnd() in gzip compression sink
  In-Reply-To: <CAAZLFmQeS4AFC6mNQNhyZWGUMXEkOmQA11UL28N-6c=CYtqnoA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox