pgsql: Server-side gzip compression.

From: Robert Haas <rhaas(at)postgresql(dot)org>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Server-side gzip compression.
Date: 2022-01-24 20:14:33
Message-ID: E1nC5jV-0001OS-4M@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Server-side gzip compression.

pg_basebackup's --compression option now lets you write either
"client-gzip" or "server-gzip" instead of just "gzip" to specify
where the compression should be performed. If you write simply
"gzip" it's taken to mean "client-gzip" unless you also use
--target, in which case it is interpreted to mean "server-gzip",
because that's the only thing that makes any sense in that case.

To make this work, the BASE_BACKUP command now takes new
COMPRESSION and COMPRESSION_LEVEL options.

At present, pg_basebackup cannot decompress .gz files, so
server-side compression will cause a failure if (1) -Ft is not
used or (2) -R is used or (3) -D- is used without --no-manifest.

Along the way, I removed the information message added by commit
5c649fe153367cdab278738ee4aebbfd158e0546 which occurred if you
specified no compression level and told you that the default level
had been used instead. That seemed like more output than most
people would want.

Also along the way, this adds a check to the server for
unrecognized base backup options. This repairs a bug introduced
by commit 0ba281cb4bf9f5f65529dfa4c8282abb734dd454.

This commit also adds some new test cases for pg_verifybackup.
They take a server-side backup with and without compression, and
then extract the backup if we have the OS facilities available
to do so, and then run pg_verifybackup on the extracted
directory. That is a good test of the functionality added by
this commit and also improves test coverage for the backup target
patch (commit 3500ccc39b0dadd1068a03938e4b8ff562587ccc) and for
pg_verifybackup itself.

Patch by me, with a bug fix by Jeevan Ladhe. The patch set of which
this is a part has also had review and/or testing from Tushar Ahuja,
Suraj Kharage, Dipesh Pandit, and Mark Dilger.

Discussion: http://postgr.es/m/CA+Tgmoa-ST7fMLsVJduOB7Eub=2WjfpHS+QxHVEpUoinf4bOSg@mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/0ad8032910d5eb8efd32867c45b6a25c85e60f50

Modified Files
--------------
doc/src/sgml/protocol.sgml | 22 +++
doc/src/sgml/ref/pg_basebackup.sgml | 29 ++-
src/backend/Makefile | 2 +-
src/backend/replication/Makefile | 1 +
src/backend/replication/basebackup.c | 54 ++++++
src/backend/replication/basebackup_gzip.c | 309 ++++++++++++++++++++++++++++++
src/bin/pg_basebackup/pg_basebackup.c | 136 +++++++++++--
src/bin/pg_verifybackup/Makefile | 7 +
src/bin/pg_verifybackup/t/008_untar.pl | 104 ++++++++++
src/include/replication/basebackup_sink.h | 1 +
10 files changed, 641 insertions(+), 24 deletions(-)

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2022-01-24 20:34:14 pgsql: Fix limitations on what SQL commands can be issued to a walsende
Previous Message Robert Haas 2022-01-24 19:43:35 pgsql: pg_upgrade: Preserve database OIDs.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-01-24 20:14:59 Re: refactoring basebackup.c
Previous Message Robert Haas 2022-01-24 20:10:05 Re: [BUG]Update Toast data failure in logical replication