Date: Thu, 31 Mar 2022 11:34:52 +0900
From: Michael Paquier <michael@paquier.xyz>
To: gkokolatos@pm.me
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	Rachel Heaton <rachelmheaton@gmail.com>, Greg Stark <stark@mit.edu>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Add LZ4 compression in pg_dump
Message-ID: <YkUTTK7dS6Zyeg9r@paquier.xyz>
References: 
 <faUNEOpts9vunEaLnmxmG-DldLSg_ql137OC3JYDmgrOMHm1RvvWY2IdBkv_CRxm5spCCb_OmKNk2T03TMm0fBEWveFF9wA1WizPuAgB7Ss=@protonmail.com>
 <20220325132253.GD28503@telsasoft.com>
 <CADJcwiUbfBV0oNNpKvd2H4kP7m2U+7SmL-GAGO8Uv5H3HZUbAw@mail.gmail.com>
 <PSMV5cBDnG2Wd93aYAyTE9RxCPpO0K7ZZQezDkqxwrDTrnp0R8fokD3N8JcmxmuHqAI4cRp_vMmPSUu1igCtaZfk-rLwoSWuBoFiCcRl8WQ=@pm.me>
 <Yj6rXhLLW3h1vYt0@paquier.xyz>
 <20220326061441.GH28503@telsasoft.com>
 <YkK05K+0tjwmhLre@paquier.xyz>
 <yTrMijGhpyxYVVeJuJPM5NandUq_5Qq647cqNuUpVkXSfbYPDj0VLfRK72jB2HWoeDgRIYIbjG7YbBrUuzv8fRF9Y5vALIrM9BGIgQLh8vM=@pm.me>
 <YkPwmndklVKG4PE+@paquier.xyz>
 <bZeDkb5raMHiji1UIjvXjVIwc5qCHcdAb5h3CXXp85D8Mjwrm4kIGPh8UVbc2sJlfKgx2KsDHSrF35JAr-kFW5GJOx8YQlLKLv5vmAYLEjQ=@pm.me>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="voBCY8jmdVbMDM1Q"
Content-Disposition: inline
In-Reply-To: 
 <bZeDkb5raMHiji1UIjvXjVIwc5qCHcdAb5h3CXXp85D8Mjwrm4kIGPh8UVbc2sJlfKgx2KsDHSrF35JAr-kFW5GJOx8YQlLKLv5vmAYLEjQ=@pm.me>
Archived-At: 
 <https://www.postgresql.org/message-id/YkUTTK7dS6Zyeg9r%40paquier.xyz>
Precedence: bulk


--voBCY8jmdVbMDM1Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 30, 2022 at 03:32:55PM +0000, gkokolatos@pm.me wrote:
> On Wednesday, March 30th, 2022 at 7:54 AM, Michael Paquier <michael@paqui=
er.xyz> wrote:
>> While moving on with 0002, I have noticed the following in
>>
>> _StartBlob():
>>     if (AH->compression !=3D 0)
>>         sfx =3D ".gz";
>>     else
>>         sfx =3D "";
>>
>> Shouldn't this bit also be simplified, adding a fatal() like the other
>> code paths, for safety?
>=20
> Agreed. Fixed.

Okay.  0002 looks fine as-is, and I don't mind the extra fatal()
calls.  These could be asserts but that's not a big deal one way or
the other.  And the cleanup is now applied.

>> + my $compress_program =3D $ENV{GZIP_PROGRAM};
>>
>> It seems to me that it is enough to rely on {compress_cmd}, hence
>> there should be no need for $compress_program, no?
>=20
> Maybe not. We don't want to the tests to fail if the utility is not
> installed. That becomes even more evident as more methods are added.
> However I realized that the presence of the environmental variable does
> not guarrantee that the utility is actually installed. In the attached,
> the existance of the utility is based on the return value of system_log().

Hmm.  [.. thinks ..]  The thing that's itching me here is that you
align the concept of compression with gzip, but that's not going to be
true once more compression options are added to pg_dump, and that
would make $supports_compression and $compress_program_exists
incorrect.  Perhaps the right answer would be to rename all that with
a suffix like "_gzip" to make a difference?  Or would there be enough
control with a value of "compression_gzip" instead of "compression" in
test_key?

+my $compress_program_exists =3D (system_log("$ENV{GZIP_PROGRAM}", '-h',
+                                         '>', '/dev/null') =3D=3D 0);
Do we need this command execution at all?  In all the other tests, we
rely on a simple "if (!defined $gzip || $gzip eq '');", so we could do
the same here.

A last thing is that we should perhaps make a clear difference between
the check that looks at if the code has been built with zlib and the
check for the presence of GZIP_PROGRAM, as it can be useful in some
environments to be able to run pg_dump built with zlib, even if the
GZIP_PROGRAM command does not exist (I don't think this can be the
case, but other tests are flexible).  As of now, the patch relies on
pg_dump enforcing uncompression if building under --without-zlib even
if --compress/-Z is used, but that also means that those compression
tests overlap with the existing tests in this case.  Wouldn't it be
more consistent to check after $supports_compression when executing
the dump command for test_key =3D "compression[_gzip]"?  This would mean
keeping GZIP_PROGRAM as sole check when executing the compression
command.
--
Michael

--voBCY8jmdVbMDM1Q
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmJFE0wACgkQnvQgOdby
QH0Gvw/5ASSQ14n/wuwDU5IfV+mr14c4dTcwOVN5EDjTUbhAfET+BwM6E+MMnvi8
vHx6W0npbFGCiO+/RH5qtMbpdiLDIJQ1H5gHWXbQe4fDfcul/GuhkzR/kAT/4e8Y
f06HymK8OD3hbpEZGFH0MrU2LBBzShixgDc7ClbuJ58rWfEIH8w0AJJZIP4p9g5g
k6bJk2AD51kyIDWmdcXW7vJCRSqqtZWLPQiWBu8N9tM84TFaIB5+OcBI8lrkAjN2
Q29fqRii7k/bEg9blrHRcRVjjq33rVJp2kZlAHz1ufPqcMQB16fDM3jarPTI187s
XNiIPBJE42UGxsaiynxMMF50BmhsP0BxpN1TQ120ICybclo9CMdEGEhT/C6kiF8B
DzjtZPVg4Sn/jyp6Kk2XhH2oEUaePoQpGOJgfyP7Rxe0j1jzr3TagV2z3D8ZR2wC
Mc/dcX3Ura9ktaF9j8BcRNVAnVAjdH40IU0XIgWRYJL0FjfBHrchHw57dm6xLHP9
kvnCLtvGjwRJaeWbQtG8C/KEg1RmI8lGez5CwKc9QNVfnhwDYlx+WS0EueG6gP4V
vk5skRHCS3sHFtIkVw51qHa6vvW51pBbVx9pC0Ldu6zXiU0QwojOdc6z9GxJ1jKv
9LPtrhDyFJswyZNrfGtsYndaBzrReEGCHpnjmvn99AonKGjAaUA=
=czu4
-----END PGP SIGNATURE-----

--voBCY8jmdVbMDM1Q--