From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | gkokolatos(at)pm(dot)me, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Rachel Heaton <rachelmheaton(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add LZ4 compression in pg_dump |
Date: | 2025-10-12 17:24:37 |
Message-ID: | 25345.1760289877@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
[ blast-from-the-past department ]
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> At the end I am finishing with the attached. I also saw an overlap
> with the addition of --jobs for the directory format vs not using the
> option, so I have removed the case where --jobs was not used in the
> directory format.
(This patch became commit 98fe74218.)
I am wondering if you remember why this bit:
+ # Give coverage for manually compressed blob.toc files during
+ # restore.
+ compress_cmd => {
+ program => $ENV{'GZIP_PROGRAM'},
+ args => [ '-f', "$tempdir/compression_gzip_dir/blobs.toc", ],
+ },
was set up to manually compress blobs.toc but not the main TOC in the
toc.dat file. It turns out that Gzip_read is broken for the case
of a zero-length read request [1], but we never reach that case
unless toc.dat is compressed. We don't cover the getc_func member
of the compression stream API, either.
I thought for a bit about proposing that we compress toc.dat but not
blobs.toc, but that loses coverage in another way: the gets_func API
turns out to be used only while reading blobs.toc. So we need to
compress both files manually if we want full coverage.
I think this change won't lose coverage, because there are other tests
in 002_pg_dump.pl that exercise directory format without extra
compression of anything.
Thoughts?
regards, tom lane
[1] https://www.postgresql.org/message-id/3686.1760232320%40sss.pgh.pa.us
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-10-12 17:27:24 | Re: Is there public API to fetch errcode? |
Previous Message | Sergey Fukanchik | 2025-10-12 16:04:40 | Is there public API to fetch errcode? |