Horton

Re: Refactoring of compression options in pg_basebackup

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Magnus Hagander <magnus@hagander.net>, Georgios Kokolatos <gkokolatos@pm.me>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>
Date: 2022-01-26T20:24:25Z
Lists: pgsql-hackers 
On Tue, Jan 25, 2022 at 8:15 PM Michael Paquier <michael@paquier.xyz> wrote:
> Sure, but I don't think that it is a good idea to unify that yet, at
> least not until pg_dump is able to handle LZ4 as an option, as the
> main benefit that we'd gain here is to be able to change the code to a
> switch/case without defaults where we would detect code paths that
> require a refresh once adding support for a new option.

I think those places could just throw a "lz4 compression is not
supported" elog() and then you could just grep for everyplace where
that string appears. But I am not of a mind to fight about it. I was
just pointing out the duplication.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Extend the options of pg_basebackup to control compression

  2. Add TAP tests for pg_basebackup with compression

  3. Refactor tar method of walmethods.c to rely on the compression method