On Mon, Apr 11, 2022 at 2:52 AM Michael Paquier <mich...@paquier.xyz> wrote: > Since babbbb5 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 > range is 1-9. If passing down 0, we'd get an error rather than > implying no compression, contrary to what we did in ~14. > > I initially thought that this was fine as-is, but then Robert and > others have worked on client/server compression for pg_basebackup, > introducing a much better design with centralized APIs where one can > use METHOD:DETAIL for as compression value, where DETAIL is a > comma-separated list of keyword=value (keyword = "level" or > "workers"), with centralized checks and an extensible design. > > 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 of the recent work done by Robert and others > for pg_basebackup:
+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. -- Robert Haas EDB: http://www.enterprisedb.com
