Horton

Thread

Commits

  1. Doc: improve description of pgbench script weights.

  1. pgbench failed when -f option contains a char '@'

    Wang, Shenhao <wangsh.fnst@cn.fujitsu.com> — 2020-12-18T06:22:36Z

    Hi, hackers

pgbench use -f filename[@weight] to receive a sql script file with a weight,
but if I create a file contains char'@', like a@2.sql, specify this file without weigth,
pgbench will failed with error:
	pgbench: fatal: invalid weight specification: @2.sql

This action may be unfriendly, because the char '@' is a valid character on Linux
and Windows.

I have created a patch to modify this action. The patch is attached.

Thoughts?

Regards
Shenhao Wang

  2. Re: pgbench failed when -f option contains a char '@'

    Heikki Linnakangas <hlinnaka@iki.fi> — 2020-12-18T08:59:33Z

    On 18/12/2020 08:22, Wang, Shenhao wrote:
> Hi, hackers
> 
> pgbench use -f filename[@weight] to receive a sql script file with a weight,
> but if I create a file contains char'@', like a@2.sql, specify this file without weigth,
> pgbench will failed with error:
> 	pgbench: fatal: invalid weight specification: @2.sql
> 
> This action may be unfriendly, because the char '@' is a valid character on Linux
> and Windows.
> 
> I have created a patch to modify this action. The patch is attached.

This patch changes it to first check if the file "a@2.sql" exists, and 
if it doesn't,  only then it tries to interpret it as a weight, as 
filename "a" and weight "2.sql". That stilll doesn't fix the underlying 
ambiguity, though. If you have a file called "script" and "script@1", 
this makes it impossible to specify "script" with weight 1, because "-f 
script@1" will now always open the file "script@1".

I think we should just leave this as it is. The user can simply rename 
the file.

Or maybe one change would be worthwhile here: First check if the part 
after the @ contains only digits. If doesn't, then assume it's part of 
the filename rather than a weight. That would fix this for cases like 
"foo@1.sql", although not for "foo@1".

- Heikki

  3. Re: pgbench failed when -f option contains a char '@'

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-12-18T15:10:42Z

    Heikki Linnakangas <hlinnaka@iki.fi> writes:
> I think we should just leave this as it is. The user can simply rename 
> the file.

Yeah.  The assumption when we defined the script-weight syntax was that
there's no particular reason to use "@" in a script file name, and
I don't see why that's a bad assumption.

> Or maybe one change would be worthwhile here: First check if the part 
> after the @ contains only digits. If doesn't, then assume it's part of 
> the filename rather than a weight. That would fix this for cases like 
> "foo@1.sql", although not for "foo@1".

I do not like introducing ambiguity of that sort.  Not being entirely
clear on which script file is going to be read seems like a recipe
for security issues.

			regards, tom lane

  4. Re: pgbench failed when -f option contains a char '@'

    Fabien COELHO <coelho@cri.ensmp.fr> — 2020-12-20T13:31:57Z

    Hello,

> pgbench use -f filename[@weight] to receive a sql script file with a weight,

ISTM that I thought of this: "pgbench -f filen@me@1" does work.

   sh> touch foo@bla
   sh> pgbench -f foo@bla@1
   pgbench: fatal: empty command list for script "foo@bla"

The documentation could point this out, though.

-- 
Fabien.

  5. Re: pgbench failed when -f option contains a char '@'

    Fabien COELHO <coelho@cri.ensmp.fr> — 2020-12-20T13:43:01Z

    Hello Tom,

>> I think we should just leave this as it is. The user can simply rename
>> the file.
>
> Yeah.  The assumption when we defined the script-weight syntax was that
> there's no particular reason to use "@" in a script file name, and
> I don't see why that's a bad assumption.

The "parser" looks for the last @ in the argument, so the simple 
workaround is to append "@1".

I suggest the attached doc update, or anything in better English.

-- 
Fabien.

  6. Re: pgbench failed when -f option contains a char '@'

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-12-20T18:38:06Z

    Fabien COELHO <coelho@cri.ensmp.fr> writes:
> The "parser" looks for the last @ in the argument, so the simple 
> workaround is to append "@1".
> I suggest the attached doc update, or anything in better English.

Agreed, done.

			regards, tom lane