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 >
