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 1o8kF6-0004kO-DX for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 15:13:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o8kF5-0003dG-7D for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 15:13:35 +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 1o8kF4-0003d5-N3 for pgsql-hackers@lists.postgresql.org; Tue, 05 Jul 2022 15:13:34 +0000 Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o8kF0-0007ZZ-W6 for pgsql-hackers@lists.postgresql.org; Tue, 05 Jul 2022 15:13:33 +0000 Received: by mail-qk1-x72f.google.com with SMTP id b125so8881697qkg.11 for ; Tue, 05 Jul 2022 08:13:30 -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:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=6DHpHe+UxB+pUwcbakdk4JGJCfb+2OYIKSti4njwLlE=; b=AMweoh8eFp7iO3yOiGg8H9nySK6wQ0SEFNjIqj9vBeAeupPIVu3FaCKrW3hiK17xGQ G0uJO6oVMwNPiFSWm04vHUp+k162YtD6ASxfH39z1H/YZq7qzM132fRGzKC1w0p4ZvWK WUxaMCVGVRa2OS/qLVpIP37y0AIXPjpXdHQCy6jCm7Qmc4J/RVYmpMvFBK4K5tX/e9fG pxHVAkgHXVvkFIOdSX3Di9bYAQrE6bjgDMX3qAoRkGN79eKQui2qtIjzltw+pHkxanxk KP9W6c1FaRkMhr+5NLKq8adtZN/3E5nKRG6eztxBS0jm7/ZZSPufPuBQR5FRvrQEIWNz JIpg== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=6DHpHe+UxB+pUwcbakdk4JGJCfb+2OYIKSti4njwLlE=; b=yWtjJoN4+3nhpCLfz0mUts6U8expGLkeH7mYQUr3il/SReQdxJtnHMflzFjBP1698H U2nRe/U30dqbfVDWmoOPVdqfo9Kv5XaDvKVMolNGyHOduNbDMyvu6kY0G/10qrsIaTJz yQsDf9YwRCpdfuDav4PhUhs9z3amhjyk/bBopii9+PKPomlQrtehftQMXKF9D/XqnVfV InXug/FwvAb3cil2PbIlBYJkGd6WZCjqWw/ou0QOC2fWZd0gDT/+VVQxqUAiugj71cKn 7S2ooVsFfbccAyVKOlXSwVM50ZqyNHVv9EY4lNJ751NeM5YWuSee02MpNiJr/7pxDZ98 oojg== X-Gm-Message-State: AJIora+ctx6fot0nIxisYdd9Re78mk9wY6NQmS5hmHWXjOYrU1PYfxba Ydvq0uNVXmyl4PnAsm8OCkZOfA== X-Google-Smtp-Source: AGRyM1sXNuO7a5eDoDv8B+jBK7/r9SdOYk2MMpN6rtqgdNAOXM9EDu0Mz3jyQ7gLWVwZ6SeVL6OG8A== X-Received: by 2002:a05:620a:280b:b0:6ad:9f7f:bae5 with SMTP id f11-20020a05620a280b00b006ad9f7fbae5mr24110546qkp.499.1657034009658; Tue, 05 Jul 2022 08:13:29 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id br31-20020a05620a461f00b006af290182c8sm22601703qkb.86.2022.07.05.08.13.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2022 08:13:29 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 72DDA80086E; Tue, 5 Jul 2022 10:13:28 -0500 (CDT) Date: Tue, 5 Jul 2022 10:13:28 -0500 From: Justin Pryzby To: gkokolatos@pm.me Cc: pgsql-hackers@lists.postgresql.org, Rachel Heaton , Michael Paquier , Robert Haas Subject: Re: Add LZ4 compression in pg_dump Message-ID: <20220705151328.GQ13040@telsasoft.com> References: <20220626155532.GA9311@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 This is a review of 0001. On Tue, Jul 05, 2022 at 01:22:47PM +0000, gkokolatos@pm.me wrote: > Simply this patchset had started to divert > heavily already based on comments from Mr. Paquier who had already requested for > the APIs to be refactored to use function pointers. This is happening in 0002 of > the patchset. I said something about reducing ifdefs, but I'm having trouble finding what Michael said about this ? > > 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 The constant still seems to be used without defining a fallback or a minimum version. > > > 0003: typo: of legacy => or legacy This is still there > > > 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. This comment still applies - zlib's gz* functions are "gzip" but the others are "zlib". https://zlib.net/manual.html That affects both the 0001 and 0002 patches. Actually, I think that "gzip" should not be the name of the user-facing option, since (except for "plain" format) it isn't using gzip. +Robert, since this suggests amending parse_compress_algorithm(). Maybe "zlib" should be parsed the same way as "gzip" - I don't think we ever expose both to a user, but in some cases (basebackup and pg_dump -Fp -Z1) the output is "gzip" and in some cases NO it's zlib (pg_dump -Fc -Z1). > > > 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". I still think this could be an early, 0000 patch. > > > freebsd/cfbot is failing. This is still failing for bsd, windows and compiler warnings. Windows also has compiler warnings. http://cfbot.cputube.org/georgios-kokolatos.html Please see: src/tools/ci/README, which you can use to run check-world on 4 OS by pushing a branch to github. > > > I suggested off-list to add an 0099 patch to change LZ4 to the default, to > > > exercise it more on CI. What about this ? I think the patch needs to pass CI on all 4 OS with default=zlib and default=lz4. > > On Sat, Mar 26, 2022 at 01:33:36PM -0500, Justin Pryzby wrote: > @@ -254,7 +251,12 @@ CreateArchive(const char *FileSpec, const ArchiveFormat fmt, > Archive * > OpenArchive(const char *FileSpec, const ArchiveFormat fmt) > { > - ArchiveHandle *AH = _allocAH(FileSpec, fmt, 0, true, archModeRead, setupRestoreWorker); > + ArchiveHandle *AH; > + pg_compress_specification compress_spec; Should this be initialized to {0} ? > @@ -969,6 +969,8 @@ NewRestoreOptions(void) > opts->format = archUnknown; > opts->cparams.promptPassword = TRI_DEFAULT; > opts->dumpSections = DUMP_UNSECTIONED; > + opts->compress_spec.algorithm = PG_COMPRESSION_NONE; > + opts->compress_spec.level = INT_MIN; Why INT_MIN ? > @@ -1115,23 +1117,28 @@ PrintTOCSummary(Archive *AHX) > ArchiveHandle *AH = (ArchiveHandle *) AHX; > RestoreOptions *ropt = AH->public.ropt; > TocEntry *te; > + pg_compress_specification out_compress_spec; Should have {0} ? I suggest to write it like my 2020 patch for this, which says: no_compression = {0}; > /* Open stdout with no compression for AH output handle */ > - AH->gzOut = 0; > - AH->OF = stdout; > + out_compress_spec.algorithm = PG_COMPRESSION_NONE; > + AH->OF = cfdopen(dup(fileno(stdout)), PG_BINARY_A, out_compress_spec); Ideally this should check the success of dup(). > @@ -3776,21 +3746,25 @@ ReadHead(ArchiveHandle *AH) > + if (AH->compress_spec.level != INT_MIN) Why is it testing the level and not the algorithm ? > --- a/src/bin/pg_dump/pg_backup_custom.c > +++ b/src/bin/pg_dump/pg_backup_custom.c > @@ -298,7 +298,7 @@ _StartData(ArchiveHandle *AH, TocEntry *te) > _WriteByte(AH, BLK_DATA); /* Block type */ > WriteInt(AH, te->dumpId); /* For sanity check */ > > - ctx->cs = AllocateCompressor(AH->compression, _CustomWriteFunc); > + ctx->cs = AllocateCompressor(AH->compress_spec, _CustomWriteFunc); Is it necessary to rename the data structure ? If not, this file can remain unchanged. > --- a/src/bin/pg_dump/pg_backup_directory.c > +++ b/src/bin/pg_dump/pg_backup_directory.c > @@ -573,6 +574,7 @@ _CloseArchive(ArchiveHandle *AH) > if (AH->mode == archModeWrite) > { > cfp *tocFH; > + pg_compress_specification compress_spec; Should use {0} ? > @@ -639,12 +642,14 @@ static void > _StartBlobs(ArchiveHandle *AH, TocEntry *te) > { > lclContext *ctx = (lclContext *) AH->formatData; > + pg_compress_specification compress_spec; Same > + /* > + * Custom and directory formats are compressed by default (zlib), others > + * not > + */ > + if (user_compression_defined == false) Should be: !user_compression_defined Your 0001+0002 patches (without 0003) fail to compile: pg_backup_directory.c: In function ‘_ReadByte’: pg_backup_directory.c:519:12: error: ‘CompressFileHandle’ {aka ‘struct CompressFileHandle’} has no member named ‘_IO_getc’ 519 | return CFH->getc(CFH); | ^~ pg_backup_directory.c:520:1: warning: control reaches end of non-void function [-Wreturn-type] 520 | } -- Justin