Re: pg_basebackup's --gzip switch misbehaves

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_basebackup's --gzip switch misbehaves
Дата
Msg-id Yyu5d/wUcEaLJje5@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_basebackup's --gzip switch misbehaves  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: pg_basebackup's --gzip switch misbehaves  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Wed, Sep 21, 2022 at 07:31:48PM -0500, Justin Pryzby wrote:
> I think at some point (maybe before releasing 1.3.4) the range was
> increased to very large(small), negative levels.  It's possible to query
> the library about the lowest supported compression level, but then
> there's a complication regarding the client-side library version vs the
> server-side version.  So it seems better to just use -7.

Indeed.  Contrary to the default level, there are no variables for the
minimum and maximum levels.  As you are pointing out, a lookup at
zstd_compress.c shows that we have ZSTD_minCLevel() and
ZSTD_maxCLevel() that assign the bounds.  Both are available since
1.4.0.  We still need a backend-side check as the level passed with a
BASE_BACKUP command would be only validated there.  It seems to me
that this is going to be less of a headache in the long-term if we
just use those routines at runtime, as zstd wants to keep some freedom
with the min and max bounds for the compression level, at least that's
the flexibility that this gives the library.  So I would tweak things
as the attached.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_basebackup --create-slot-if-not-exists?
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: pg_receivewal fail to streams when the partial file to write is not fully initialized present in the wal receiver directory