Re: pg_amcheck contrib application

> On Mar 13, 2021, at 10:46 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> On Fri, Mar 12, 2021 at 05:04:09PM -0800, Mark Dilger wrote:
>>> On Mar 12, 2021, at 3:24 PM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>>>
>>> and the second deals with an apparent problem with IPC::Run shell expanding an asterisk on some platforms but not others. That second one, if true, seems like a problem with scope beyond the pg_amcheck project, as TestLib::command_checks_all uses IPC::Run, and it would be desirable to have consistent behavior across platforms.
>
>>> One of pg_amcheck's regression tests was passing an asterisk through
>>> TestLib's command_checks_all() command, which gets through to
>>> pg_amcheck without difficulty on most platforms, but appears to get
>>> shell expanded on Windows (jacana) and AIX (hoverfly).
>
> For posterity, I can't reproduce this on hoverfly. The suite fails the same
> way at f371a4c and f371a4c^. More-recently (commit 58f5749), the suite passes
> even after reverting f371a4c. Self-contained IPC::Run usage also does not
> corroborate the theory:
>
> [nm(at)power8-aix 8:0 2021-03-13T18:32:23 clean 0]$ perl -MIPC::Run -e 'IPC::Run::run "printf", "%s\n", "*"'
> *
> [nm(at)power8-aix 8:0 2021-03-13T18:32:29 clean 0]$ perl -MIPC::Run -e 'IPC::Run::run "sh", "-c", "printf %s\\\\n *"'
> COPYRIGHT
> GNUmakefile.in
> HISTORY
> Makefile
> README
> README.git
> aclocal.m4
> config
> configure
> configure.ac
> contrib
> doc
> src
>
>> there is a similar symptom caused by an unrelated problem
>
>> Subject: [PATCH v3] Avoid use of non-portable option ordering in
>> command_checks_all().
>
> On a glibc system, "env POSIXLY_CORRECT=1 make check ..." tests this.

Thanks for investigating!

The reason I suspected that passing the '*' through IPC::Run had to do with the error that pg_amcheck gave. It complained that too many arguments where being passed to it, and that the first such argument was "pg_amcheck.c". There's no reason pg_amcheck should know it's source file name, nor that the regression test should know that, which suggested that the asterisk was being shell expanded within the src/bin/pg_amcheck/ directory and the file listing was being passed into pg_amcheck as arguments.

That theory may have been wrong, but it was the only theory I had at the time. I don't have access to any of the machines where that happened, so it is hard for me to investigate further.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company