Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ndvlr-0002cZ-9i for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Apr 2022 15:16:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ndvlq-0005ur-6i for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Apr 2022 15:16:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ndvlp-0005ui-RD for pgsql-hackers@lists.postgresql.org; Mon, 11 Apr 2022 15:16:01 +0000 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ndvln-0002ev-Ja for pgsql-hackers@lists.postgresql.org; Mon, 11 Apr 2022 15:16:00 +0000 Received: by mail-lf1-x129.google.com with SMTP id x33so20791094lfu.1 for ; Mon, 11 Apr 2022 08:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HpYcJDHSWW5BO7k5zl3ua62KeUmFQfwieb0xctyrp5Q=; b=dUu5IxgslbW47d3KaU8olqmcGEd835nU58d89GN1iGFfGi7b6oi+O/Kbt0/6j+uBXr dyRdpEce1zOBbVkQQdoOjodB77PDYIJefXj3rxEAOpUvch2aRkSIZibzNv+sRm/Ealag LJQlYSwSetbX/6VHNIM2erUN4EbbtvIzYoySJw8wcYDrdN4WCb8cgO2YEWVuvbPqVls8 h/9y7U4YBHbcKhdcoBFlkFlHBTNz1bzVGTBkiTWM5ZOQ0I5PErVINL6g+PWi8myRRxuA KQastyO+IEEQQfetBAPhnpBan2nq+1Xd/T13+12EIcQ+hZ0Id1KJgspVAWmIx4AL80vm R9wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HpYcJDHSWW5BO7k5zl3ua62KeUmFQfwieb0xctyrp5Q=; b=Wsdtq7tJLN8ouga8ZBMQKuM7QPLubWZjSjLc63gcmq0/igcH9SOmnZtV54mfetX4k9 as7hoJyVzbPpWQgnSobObxINCBMjc19lIBmkAQo57o92G8uJWlXPiU+btX7BbJqT/TkZ P/5ucCu9L1fJ0juJdM0CQtAF4OjuWImv+0jePdzHXgCR4paIMaMq9iEeUmxn6cNTceSa AXB7zo0WjAW8k46jtkfq3MSE1HAcEJoX8fZBv6yA8ODRvKyeVVBlrKxCmnWtyBIWNlT2 1/wqbCyslhIrXjUC5RsIRsm5EvZSIn18yhYKUHXuCRNcu8wADSwFjZMQmK40pcodf3mT Lqnw== X-Gm-Message-State: AOAM53108XxpBN0CNssz1HmotF/B3rVWauVkIy49EIuL/NTwXq0HWzsW l66dHufFRRY98zCJZMu5Xqq61ePFCxJmTXxNNKI= X-Google-Smtp-Source: ABdhPJxWHBbg0mCkL6L4Jy753MrTDzfGr2L3QwVw0CzKYGt0WVK9W18/672L0jBhUQNuwiSRbPmuSmaBmPcRhNbbtSU= X-Received: by 2002:a05:6512:1111:b0:46b:b2dc:ce27 with SMTP id l17-20020a056512111100b0046bb2dcce27mr933153lfg.368.1649690157604; Mon, 11 Apr 2022 08:15:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Haas Date: Mon, 11 Apr 2022 11:15:46 -0400 Message-ID: Subject: Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h} To: Michael Paquier Cc: Postgres hackers , Georgios Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Apr 11, 2022 at 2:52 AM Michael Paquier 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