Re: Add LZ4 compression in pg_dump

From: gkokolatos(at)pm(dot)me
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Rachel Heaton <rachelmheaton(at)gmail(dot)com>
Subject: Re: Add LZ4 compression in pg_dump
Date: 2023-01-25 19:57:18
Message-ID: 4ZDVII-_kusch7xndcrTUt7OPSuQWQGX7n8rqp625Hdv6DijBjWZ38gjhxLSzPu8M_Dka-50eeKCiCU_dOdawwpv06dZtwGroYE9dHlIBLc=@pm.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

------- Original Message -------
On Wednesday, January 25th, 2023 at 7:00 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:

>
>
> On Wed, Jan 25, 2023 at 03:37:12PM +0000, gkokolatos(at)pm(dot)me wrote:
>

> While looking at this, I realized that commit 5e73a6048 introduced a
> regression:
>
> @@ -3740,19 +3762,24 @@ ReadHead(ArchiveHandle *AH)
>
> - if (AH->compression != 0)
>
> - pg_log_warning("archive is compressed, but this installation does not support compression -- no data will be available");
> + if (AH->compression_spec.algorithm == PG_COMPRESSION_GZIP)
>
> + pg_fatal("archive is compressed, but this installation does not support compression");
>
> Before, it was possible to restore non-data chunks of a dump file, even
> if the current build didn't support its compression. But that's now
> impossible - and it makes the code we're discussing in RestoreArchive()
> unreachable.

Nice catch!

Cheers,
//Georgios

> --
> Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message SATYANARAYANA NARLAPURAM 2023-01-25 20:27:30 Re: Improve WALRead() to suck data directly from WAL buffers when possible
Previous Message Aleksander Alekseev 2023-01-25 19:55:48 Re: to_hex() for negative inputs