| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_basebackup's --gzip switch misbehaves |
| Date: | 2022-09-14 05:18:03 |
| Message-ID: | 2529394.1663132683@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> And so, I have spent a couple of hours torturing the patch, applying
> it after a few tweaks and CI runs:
> ...
> The buildfarm is green so I think that we are good. I have closed the
> open item.
+1, thanks for taking care of that.
As far as my original complaint about mamba goes, I've not quite
been able to run it to ground. However, I found that NetBSD
seems to be shipping unmodified zlib 1.2.11, which contains a
number of known bugs in deflate_stored() --- that is, the code
path implementing compression level 0. Red Hat for one is
carrying several back-patched fixes in that part of zlib.
So for the moment I'm willing to write it off as "not our bug".
We aren't intentionally testing compression level 0, and hardly
anybody would intentionally use it in the field, so it's not
really a thing worth worrying about IMO. But if mamba continues
to show failures in that test then it will be worth looking closer.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-09-14 05:25:30 | Re: archive modules |
| Previous Message | houzj.fnst@fujitsu.com | 2022-09-14 05:10:32 | RE: why can't a table be part of the same publication as its schema |