------- Original Message -------
On Wednesday, March 1st, 2023 at 5:20 PM, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
>
>
>
>
> On 2/25/23 15:05, Justin Pryzby wrote:
>
> > On Fri, Feb 24, 2023 at 11:02:14PM -0600, Justin Pryzby wrote:
> >
> > > I have some fixes (attached) and questions while polishing the patch for
> > > zstd compression. The fixes are small and could be integrated with the
> > > patch for zstd, but could be applied independently.
> >
> > One more - WriteDataToArchiveGzip() says:
> >
> > + if (cs->compression_spec.level == 0)
> > + pg_fatal("requested to compress the archive yet no level was specified");
> >
> > That was added at e9960732a.
> >
> > But if you specify gzip:0, the compression level is already enforced by
> > validate_compress_specification(), before hitting gzip.c:
> >
> > | pg_dump: error: invalid compression specification: compression algorithm "gzip" expects a compression level
between1 and 9 (default at -1)
> >
> > 5e73a6048 intended that to work as before, and you can specify -Z0:
> >
> > The change is backward-compatible, hence specifying only an integer
> > leads to no compression for a level of 0 and gzip compression when the
> > level is greater than 0.
> >
> > $ time ./src/bin/pg_dump/pg_dump -h /tmp regression -t int8_tbl -Fp --compress 0 |file -
> > /dev/stdin: ASCII text
>
>
> FWIW I agree we should make this backwards-compatible - accept "0" and
> treat it as no compression.
>
> Georgios, can you prepare a patch doing that?
Please find a patch attached. However I am a bit at a loss, the backwards
compatible behaviour has not changed. Passing -Z0/--compress=0 does produce
a non compressed output. So I am not really certain as to what broke and
needs fixing.
What commit 5e73a6048 did fail to do, is test the backwards compatible
behaviour. The attached amends it.
Cheers,
//Georgios
>
>
> regards
> --
> Tomas Vondra
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company