| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jianghua Yang <yjhjstz(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: basebackup: add missing deflateEnd() in gzip compression sink |
| Date: | 2026-03-23 00:31:36 |
| Message-ID: | acCJ6C-LHbJWSVEJ@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-03-23 00:42:19 | Re: amcheck: fix bug of missing corruption in allequalimage validation |
| Previous Message | Andrew Jackson | 2026-03-22 23:38:41 | Re: Add ldapservice connection parameter |