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

 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 <michael@paquier.xyz> 于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
>