Re: Introduce pg_receivewal gzip compression tests

From: gkokolatos(at)pm(dot)me
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Introduce pg_receivewal gzip compression tests
Date: 2021-07-15 13:49:07
Message-ID: lzYu3OfBaWAkfyLOUFXLSW93D3K44L3lLyFIuVwBXQNVza22qftxc_5zd2tapYwNNkZkW9M5wUEyKvt8NZ3N2rzcXT8fGUYeNks-5RwUYFk=@pm.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Thursday, July 15th, 2021 at 14:35, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Thu, Jul 15, 2021 at 08:35:27PM +0900, Michael Paquier wrote:

>
> > 2. curculio:
> > Looking at the OpenBSD code (usr.bin/compress/main.c), long options
> > are supported, where --version does exit(0) without printing
> > set_outfile() is doing a discard of the file suffixes it does not
> > recognize, and I think that their implementation bumps on .gz.partial
> > and generates an exit code of 512 to map with WARNING. I still wish
> > to keep this test, and I'd like to think that the contents of
> > @zlib_wals are enough in terms of coverage. What do you think?
>
> After thinking more about this one, I have taken the course to just
> remove the .gz.partial segment from the check, a full segment should
> be enough in terms of coverage. I prefer this simplification over a
> rename of the .partial segment or a tweak of the error code to map
> with WARNING.

Fair enough.

Cheers,
//Georgios

> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-07-15 13:50:08 Re: 回复: Why is XLOG_FPI_FOR_HINT always need backups?
Previous Message James Coleman 2021-07-15 13:44:14 Re: [PATCH] Use optimized single-datum tuplesort in ExecSort