Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-17 Thread Michael Paquier
On Thu, Apr 14, 2022 at 06:18:29AM +0900, Michael Paquier wrote: > 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. I have looked at that again this morning, and the

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-13 Thread Michael Paquier
On Wed, Apr 13, 2022 at 02:58:28PM +, gkokola...@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

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-13 Thread gkokolatos
--- Original Message --- On Wednesday, April 13th, 2022 at 7:25 AM, Michael Paquier wrote: > > > On Tue, Apr 12, 2022 at 06:22:48PM +0900, Michael Paquier wrote: > > > On Mon, Apr 11, 2022 at 12:46:02PM +, gkokola...@pm.me wrote: > > > > > It looks good. If you choose to discard

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-12 Thread Michael Paquier
On Tue, Apr 12, 2022 at 06:22:48PM +0900, Michael Paquier wrote: > On Mon, Apr 11, 2022 at 12:46:02PM +, gkokola...@pm.me wrote: >> It looks good. If you choose to discard the comment regarding the use of >> 'method' over 'algorithm' from above, can you please use the full word in the >>

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-12 Thread Michael Paquier
On Mon, Apr 11, 2022 at 12:46:02PM +, gkokola...@pm.me wrote: > On Monday, April 11th, 2022 at 8:52 AM, Michael Paquier > wrote: >> - 0001 is a simple rename of backup_compression.{c,h} to >> compression.{c,h}, removing anything related to base backups from >> that. One extra reason behind

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-11 Thread Michael Paquier
On Mon, Apr 11, 2022 at 11:15:46AM -0400, Robert Haas wrote: > +1 for this in general, but I think that naming like > "compression_algo" stinks. If you think "compression_algorithm" is too > long, I think you should use "algorithm" or "compression" or > "compression_method" or something. Yes, I

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-11 Thread Robert Haas
On Mon, Apr 11, 2022 at 2:52 AM Michael Paquier wrote: > Since ba5 and the introduction of LZ4, I have reworked the way > compression is controlled for pg_receivewal, with two options: > - --compress-method, settable to "gzip", "none" or "lz4". > - --compress, to pass down a compression

Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-11 Thread gkokolatos
On Monday, April 11th, 2022 at 8:52 AM, Michael Paquier wrote: > This is something I think we had better fix before beta1, because now > we have binaries that use an inconsistent set of options. So, > attached is a patch set aimed at rework this option set from the > ground, taking advantage

Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}

2022-04-11 Thread Michael Paquier
Hi all, (Added Robert and Georgios in CC:) Since ba5 and the introduction of LZ4, I have reworked the way compression is controlled for pg_receivewal, with two options: - --compress-method, settable to "gzip", "none" or "lz4". - --compress, to pass down a compression level, where the allowed