Re: pg_basebackup's --gzip switch misbehaves

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_basebackup's --gzip switch misbehaves
Date: 2022-09-22 04:34:04
Message-ID: YyvlvO/hBkQxDN1H@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 21, 2022 at 11:43:56PM -0400, Tom Lane wrote:
> I don't have any opinion on the concrete merits of this change,
> but I want to note that 15rc1 wraps on Monday, and we don't like
> people pushing noncritical changes shortly before a wrap. There
> is not a lot of time for fooling around here.

If I were to do it in the next couple of hours, we'd still have quite
a couple of days of coverage, which is plenty as far as I understand?

Saying that, it is not a critical change. Just to give some numbers,
for a fresh initdb's instance base.tar.zst is at:
- 3.6MB at level 0.
- 3.8MB at level 1.
- 3.6MB at level 2.
- 4.3MB at level -1.
- 4.6MB at level -2.
- 6.1MB at level -7.

I am not sure if there would be a huge demand for this much control
over the current [1,22], but the library wants to control dynamically
the bounds and has the APIs to allow that.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-09-22 04:37:01 Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory
Previous Message Nathan Bossart 2022-09-22 04:22:48 Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans