Re: pgsql: Allow db.schema.table patterns, but complain about random garbag

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Allow db.schema.table patterns, but complain about random garbag
Date: 2022-04-23 02:59:27
Message-ID: 20220423025927.GA1274057@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Apr 23, 2022 at 09:12:20AM +1200, Thomas Munro wrote:
> On Sat, Apr 23, 2022 at 8:06 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > I have to say the fact that IPC::Run does shell-glob expansion of its
> > arguments on some machines and not others seems ludicrous to me. This
> > patch may be overtested, but such a radical behavior difference is
> > completely nuts. How is anyone supposed to write reliable tests for
> > any feature in the face of such wildly inconsistent behavior?

The MinGW gcc crt*.o files do shell-glob expansion on the arguments before
entering main(). See https://google.com/search?q=mingw+command+line+glob for
various discussion of that behavior. I suspect you experienced that, not any
IPC::Run behavior. (I haven't tested, though.) Commit 11e9caf likely had the
same cause, though the commit message attributed it to the msys shell rather
than to crt*.o.

Let's disable that MinGW compiler behavior.
https://willus.com/mingw/_globbing.shtml lists two ways of achieving that.

> Yeah, I was speculating that it's a bug in IPC::Run that has been
> fixed (by our very own Noah), and some of the machines are still
> running the buggy version.

That change affected arguments containing double quote characters, but mere
asterisks shouldn't need it. It also has not yet been released, so few or no
buildfarm machines are using it.

> (Not a Windows person, but I speculate the reason that such a stupid
> bug is even possible may be that Windows lacks a way to 'exec' stuff
> with a passed-in unadulterated argv[] array, so you always need to
> build a full shell command subject to interpolation, so if you're
> trying to emulate an argv[]-style interface you have to write the code
> to do the escaping, and so everyone gets a chance to screw that up.)

You needn't involve any shell. Other than that, your description pretty much
says it. CreateProcessA() is the Windows counterpart of execve(). There's no
argv[] array, just a single string. (The following trivia does not affect
PostgreSQL.) Worse, while there's a typical way to convert that string to
argv[] at program start, some programs do it differently. You need to know
your callee in order to construct the string:
https://github.com/toddr/IPC-Run/pull/148/commits/c299a86c9a292375fbfc39fb756883c80adac4b0#diff-5833a343d19ba684779743e2c90516fc65479609274731785364d2d2b49e2211

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Noah Misch 2022-04-23 03:21:56 pgsql: Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8.
Previous Message Tom Lane 2022-04-22 23:08:05 Re: pgsql: Remove some recently-added pg_dump test cases.

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-04-23 05:57:46 Re: [Proposal] vacuumdb --schema only
Previous Message David Christensen 2022-04-22 22:51:24 [PATCH] Teach pg_waldump to extract FPIs from the WAL