On Sat, Feb 12, 2022 at 11:12:50PM -0500, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Well, this somebody is I, and the buildfarm did not blow up on any of
>> that so that looked rather fine.
>
> Eh? copperhead for one is failing for exactly this reason:
>
> Bailout called. Further testing stopped: failed to execute command
> "lz4 -d -m
>
/home/pgbf/buildroot/HEAD/pgsql.build/src/bin/pg_verifybackup/tmp_check/t_008_untar_primary_data/backup/server-backup/base.tar.lz4":
> No such file or directory
Well, I have put in place a check in the TAP tests, that Robert has
managed to break. It looks like it was wrong of me to assume that
it would be fine as-is. Sorry about that.
>> Adding a few cycles for this check
>> is fine by me. What do you think of the attached?
>
> Looks OK as far as it goes ... but do we need anything on the
> MSVC side?
It is possible to tweak the environment variable so one can unset it.
If we make things consistent with the configure check, we could tweak
the default to not be "lz4" if we don't have --with-lz4 in the MSVC
configuration? I don't recall seeing in the wild an installer for LZ4
where we would have the command but not the libraries, so perhaps
that's not worth the trouble, anyway, and we don't have any code paths
in the tests where we use LZ4 without --with-lz4.
> Also, I can't help wondering why we have both GZIP_PROGRAM and GZIP
> variables. I suppose that's a separate issue though.
From gzip's man page:
"The obsolescent environment variable GZIP can hold a set of default
options for gzip."
This means that saving the command into a variable with the same name
interacts with the command launch. This was discussed here:
https://www.postgresql.org/message-id/nr63G0R6veCrLY30QMwxYA2aCawclWJopZiKEDN8HtKwIoIqZ79fVmSE2GxTyPD1Mk9FzRdfLCrc-BSGO6vTlDT_E2-aqtWeEiNn-qsDDzk=@pm.me
--
Michael
