Re: Refactoring of compression options in pg_basebackup
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Georgios Kokolatos <gkokolatos@pm.me>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>
Date: 2022-01-14T21:53:12Z
Lists: pgsql-hackers
On Thu, Jan 13, 2022 at 10:23 PM Michael Paquier <michael@paquier.xyz> wrote: > Using --compression-level=NUMBER and --server-compress=METHOD to > specify a server-side compression method with a level is fine by me, > but I find the reuse of --compress to specify a compression method > confusing as it maps with the past option we have kept in > pg_basebackup for a couple of years now. Based on your suggested set > of options, we could then have a --client-compress=METHOD and > --compression-level=NUMBER to specify a client-side compression method > with a level. If we do that, I guess that we should then: > 1) Block the combination of --server-compress and --client-compress. > 2) Remove the existing -Z/--compress and -z/--gzip. I could live with that. I'm not sure that --client-compress instead of reusing --compress is going to be better ... but I don't think it's awful so much as just not my first choice. I also don't think it would be horrid to leave -z, --gzip, and -Z as shorthands for the --client-compress=gzip with --compression-level also in the last case, instead of removing all that stuff. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Extend the options of pg_basebackup to control compression
- 5c649fe15336 15.0 landed
-
Add TAP tests for pg_basebackup with compression
- 50e144193c77 15.0 landed
-
Refactor tar method of walmethods.c to rely on the compression method
- 000f3adfdc43 15.0 landed