Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h} - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}
Date
Msg-id Ylc+JXBBTfqidtPc@paquier.xyz
Whole thread Raw
In response to Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}  (gkokolatos@pm.me)
Responses Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, Apr 13, 2022 at 02:58:28PM +0000, gkokolatos@pm.me wrote:
> It's really not hard to add compression level. However we had briefly
> discussed it in the original thread [1] and decided against. That is why
> I did not write that code. If the community thinks differently now, let
> me know if you would like me to offer a patch for it.

The issue back then was how to design the option set to handle all
that (right?  My memories may be short on that), and pg_basebackup
takes care of that with its option design.

This is roughly what has been done here, except that this was for the
contentSize:

https://www.postgresql.org/message-id/rYyZ3Fj9qayyY9-egNsV_kkLbL_BSWcOEdi3Mb6M9eQRTkcA2jrqFEHglLUEYnzWR_wttCqn7VI94MZ2p7mwNje51lHTvWYnJ1jHdOceen4=@pm.me

Do you think that the extra test coverage is going to be too much of a
burden?  I was thinking about just adding a level to the main lz4
command, with an extra negative test in the SKIP block with a level
out of range
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: chap@anastigmatix.net
Date:
Subject: Re: timezones BCE
Next
From: Peter Geoghegan
Date:
Subject: Re: Improving the "Routine Vacuuming" docs