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 1o5Ubs-0004M5-J6 for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Jun 2022 15:55:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o5Ubr-0000YC-5a for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Jun 2022 15:55:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o5Ubq-0000Y3-Ow for pgsql-hackers@lists.postgresql.org; Sun, 26 Jun 2022 15:55:38 +0000 Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o5Ubo-0004e2-An for pgsql-hackers@lists.postgresql.org; Sun, 26 Jun 2022 15:55:37 +0000 Received: by mail-io1-xd2f.google.com with SMTP id k15so7365130iok.5 for ; Sun, 26 Jun 2022 08:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=7z/01mpZLzUEfBpgYlTDb2RlCnYW3iqzEUai8MLBF9I=; b=oXuHzrQEMf06HtmkMNHmbCr7squig14Y59p1OiHvgUaO7jbxAfRVs6MGqO7RFZMCK+ f3uL1RL31qt2CjN7xb+ckfoTbn/eL+Kme70GqNJjj1k0P9rN+N6dYeP3pb6wUsYhOTiv yLowvWOl3YgufDLhaNosE4PPFF7/K6WjUS4S0SpSXVjFDqVX2NgVjbiyn3gfbvIfFCmn kHuGMeaAL9C7gLTdq4MMlQo/9PBq7PiNor9dBujRlSzoVdGl8mwW4I/KDw9My+EUVRgG YYiXOacQTZs534eXKOJhXcIJxjwCI12WvC5w3vdg0mgfQE5jXUru0g4/bpcKwg+SoL6b 4Fmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=7z/01mpZLzUEfBpgYlTDb2RlCnYW3iqzEUai8MLBF9I=; b=uAheiTT1/2etgCwRm2iqSMDMbwLcsOFKR+XdWEpaDChdsc8Dwf5xfIT5E0yR2Y36vu OXslyA8llqMRmN0NmmMEOQhbeclarYlCUNOp+JR8I09kUUNP6Nybd/bSrY5KDFimlUDv yz+jVUnn0nKNCYVh8MUnpOBYJpT4zt9MfFvndaPx9nflDa/QuBMrY2Y6G7rW3Mqu1Jrz 19ovt5/rKN1v3e5vcnxm9DUesc3WIa+G20MOF4NxJVJIhbXHry1uVy/fuH1gw4mjsKxc OvBMGJ6nuZYr4M6DgMMdpMQ5X0mYHSIlU7ZLVCdmRtniMM9u8jskmojgkpugXnZUItiB Wwcg== X-Gm-Message-State: AJIora/K8wqvgbiYyeN+XevEB9FHQZEkDIA8DQuYQHBiVYAriF8TWtPu fb5xRnwLPK8QNNZYvgD6OPVmA1wP0LAN0w== X-Google-Smtp-Source: AGRyM1uxinTvR26dCqs2TV2j7qWNjCR4qbnZELqXBnxjIsN2tQPdX5nyykOOpnFFUeRerWwhHRz1Sw== X-Received: by 2002:a02:a311:0:b0:33c:957a:7d2f with SMTP id q17-20020a02a311000000b0033c957a7d2fmr1212527jai.256.1656258934435; Sun, 26 Jun 2022 08:55:34 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k6-20020a02cb46000000b00331743a983asm2292904jap.179.2022.06.26.08.55.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jun 2022 08:55:33 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 8B0D0800AF9; Sun, 26 Jun 2022 10:55:32 -0500 (CDT) Date: Sun, 26 Jun 2022 10:55:32 -0500 From: Justin Pryzby To: Georgios Cc: pgsql-hackers@lists.postgresql.org, Rachel Heaton Subject: Re: Add LZ4 compression in pg_dump Message-ID: <20220626155532.GA9311@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220326183336.GJ28503@telsasoft.com> <20220326162156.GI28503@telsasoft.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, Will you be able to send a rebased patch for the next CF ? If you update for the review comments I sent in March, I'll plan to do another round of review. On Sat, Mar 26, 2022 at 11:21:56AM -0500, Justin Pryzby wrote: > LZ4F_HEADER_SIZE_MAX isn't defined in old LZ4. > > I ran into that on an ubuntu LTS, so I don't think it's so old that it > shouldn't be handled more gracefully. LZ4 should either have an explicit > version check, or else shouldn't depend on that feature (or should define a > safe fallback version if the library header doesn't define it). > > https://packages.ubuntu.com/liblz4-1 > > 0003: typo: of legacy => or legacy > > There are a large number of ifdefs being added here - it'd be nice to minimize > that. basebackup was organized to use separate files, which is one way. > > $ git grep -c 'ifdef .*LZ4' src/bin/pg_dump/compress_io.c > src/bin/pg_dump/compress_io.c:19 > > In last year's CF entry, I had made a union within CompressorState. LZ4 > doesn't need z_streamp (and ztsd will need ZSTD_outBuffer, ZSTD_inBuffer, > ZSTD_CStream). > > 0002: I wonder if you're able to re-use any of the basebackup parsing stuff > from commit ffd53659c. You're passing both the compression method *and* level. > I think there should be a structure which includes both. In the future, that > can also handle additional options. I hope to re-use these same things for > wal_compression=method:level. > > You renamed this: > > |- COMPR_ALG_LIBZ > |-} CompressionAlgorithm; > |+ COMPRESSION_GZIP, > |+} CompressionMethod; > > ..But I don't think that's an improvement. If you were to change it, it should > say something like PGDUMP_COMPRESS_ZLIB, since there are other compression > structs and typedefs. zlib is not idential to gzip, which uses a different > header, so in WriteDataToArchive(), LIBZ is correct, and GZIP is incorrect. > > The cf* changes in pg_backup_archiver could be split out into a separate > commit. It's strictly a code simplification - not just preparation for more > compression algorithms. The commit message should "See also: > bf9aa490db24b2334b3595ee33653bf2fe39208c". > > The changes in 0002 for cfopen_write seem insufficient: > |+ if (compressionMethod == COMPRESSION_NONE) > |+ fp = cfopen(path, mode, compressionMethod, 0); > | else > | { > | #ifdef HAVE_LIBZ > | char *fname; > | > | fname = psprintf("%s.gz", path); > |- fp = cfopen(fname, mode, compression); > |+ fp = cfopen(fname, mode, compressionMethod, compressionLevel); > | free_keep_errno(fname); > | #else > > The only difference between the LIBZ and uncompressed case is the file > extension, and it'll be the only difference with LZ4 too. So I suggest to > first handle the file extension, and the rest of the code path is not > conditional on the compression method. I don't think cfopen_write even needs > HAVE_LIBZ - can't you handle that in cfopen_internal() ? > > This patch rejects -Z0, which ought to be accepted: > ./src/bin/pg_dump/pg_dump -h /tmp regression -Fc -Z0 |wc > pg_dump: error: can only specify -Z/--compress [LEVEL] when method is set > > Your 0003 patch shouldn't reference LZ4: > +#ifndef HAVE_LIBLZ4 > + if (*compressionMethod == COMPRESSION_LZ4) > + supports_compression = false; > +#endif > > The 0004 patch renames zlibOutSize to outsize - I think the patch series should > be constructed such as to minimize the size of the method-specific patches. I > say this anticipating also adding support for zstd. The preliminary patches > should have all the boring stuff. It would help for reviewing to keep the > patches split up, or to enumerate all the boring things that are being renamed > (like change OutputContext to cfp, rename zlibOutSize, ...). > > 0004: The include should use and not "lz4.h" > > freebsd/cfbot is failing. > > I suggested off-list to add an 0099 patch to change LZ4 to the default, to > exercise it more on CI. On Sat, Mar 26, 2022 at 01:33:36PM -0500, Justin Pryzby wrote: > On Sat, Mar 26, 2022 at 11:21:56AM -0500, Justin Pryzby wrote: > > You're passing both the compression method *and* level. I think there should > > be a structure which includes both. In the future, that can also handle > > additional options. > > I'm not sure if there's anything worth saving, but I did that last year with > 0003-Support-multiple-compression-algs-levels-opts.patch > I sent a rebased copy off-list. > https://www.postgresql.org/message-id/flat/20210104025321.GA9712@telsasoft.com#ca1b9f9d3552c87fa874731cad9d8391 > > | fatal("not built with LZ4 support"); > | fatal("not built with lz4 support"); > > Please use consistent capitalization of "lz4" - then the compiler can optimize > away duplicate strings. > > > 0004: The include should use and not "lz4.h" > > Also, use USE_LZ4 rather than HAVE_LIBLZ4, per 75eae0908.