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: Sun, 22 Mar 2026 18:36:22 -0700
Message-ID: <CAAZLFmRJ=6OjfrPLLbgMa5yUgSctxagD=3kjdCq_MgKCv0Ohzg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAAZLFmQNJ0QNArpWEOZXwv=vbumcWKEHz-b1me5gBqRqG67EwQ@mail.gmail.com>
	<[email protected]>
	<CAAZLFmQeS4AFC6mNQNhyZWGUMXEkOmQA11UL28N-6c=CYtqnoA@mail.gmail.com>
	<CAAZLFmQOH+fy6=ybEQ-xGdX9Zee2xkXhfuzCfbWweXxJ_6iD-A@mail.gmail.com>
	<[email protected]>

 Hi Michael,





  Thank you for reviewing and committing the patch!



  noted on v1-0002 — understood that the incremental manifest file close
isn't an issue there.


  Thanks again.





  Regards,
  Jianghua Yang

Michael Paquier <[email protected]> 于2026年3月22日周日 17:32写道：

> On Sat, Mar 21, 2026 at 02:22:25PM -0700, Jianghua Yang wrote:
> > v1-0001: basebackup: add missing deflateEnd() calls in gzip compression
> > sink
>
> After double-checking the whole code, I agree that this is a good
> practice to have in the tree.  However, the issue is not worth
> bothering in back-branches as the server-side base backup gzip code
> relies on allocation and free callbacks, with zlib internals doing
> nothing with fds or more persistent states as far as I have read its
> code.  For the current use, we'd bloat this data once per tablespace
> in a single base backup, safe even if the connection is persistent
> (missed that in my first message).
>
> What I am more worried about are future callers of this code, though,
> and we care about having a end() call for each matching init[2]() call
> in the tree in all the places that rely on gzip internals.  So that's
> a good practice on consistency ground, at least.  For these reasons,
> applied that on HEAD.
>
> > v1-0002: pg_basebackup: add missing close() for incremental manifest
> > file
>
> This one does not matter.  This resource is for a backup manifest and
> we are talking about a single one for a single invocation of the
> binary.
> --
> Michael
>

view thread (6+ messages)

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: <CAAZLFmRJ=6OjfrPLLbgMa5yUgSctxagD=3kjdCq_MgKCv0Ohzg@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