Re: refactoring basebackup.c (zstd workers) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: refactoring basebackup.c (zstd workers)
Date
Msg-id CA+TgmoaYrNxoGB8x_7Fk5uKXfbyMVAdSXTnfQN-1zu_3gB_v=Q@mail.gmail.com
Whole thread Raw
In response to Re: refactoring basebackup.c  (Jeevan Ladhe <jeevanladhe.os@gmail.com>)
Responses Re: refactoring basebackup.c (zstd workers)  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Mon, Mar 14, 2022 at 12:35 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> I suggest to use a syntax that's more general than that, maybe something like
>
> :[level=]N,parallel=N,flag,flag,...
>
> For example, someone may want to use zstd "long" mode or (when it's released)
> rsyncable mode, or specify fine-grained compression parameters (strategy,
> windowLog, hashLog, etc).

That's an interesting idea. I wonder what the replication protocol
ought to look like in that case. Should we have a COMPRESSION_DETAIL
argument that is just a string, and let the server parse it out? Or
separate protocol-level options? It does feel reasonable to have both
COMPRESSION_LEVEL and COMPRESSION_WORKERS as first-class options, but
I don't know that we want COMPRESSION_HASHLOG true as part of our
first-class grammar.

> I hope the same syntax will be shared with wal_compression and pg_dump.
> And libpq, if that patch progresses.
>
> BTW, I think this may be better left for PG16.

Possibly so ... but if we're thinking of any revisions to the
newly-added grammar, we had better take care of that now, before it's
set in stone.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Allow async standbys wait for sync replication
Next
From: Nathan Bossart
Date:
Subject: Re: add checkpoint stats of snapshot and mapping files of pg_logical dir