> Marking the patch as either Ready for Committer or Waiting on Author
will help move things along.
Thanks for the heads-up, I've retested it again and it applies cleanly on
top of master and addresses the issue.
I've moved it to `Ready for Committer`.
--
Raúl Marín Rodríguez
carto.com
On 2/8/19 3:30 PM, Raúl Marín wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Tested `pgbench-tap-glob-fix-1.pat
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Tested `pgbench-tap-glob-fix-1.patch` with a "+" in the path and the tap
> On 8 Feb 2019, at 13:33, Raúl Marín Rodríguez wrote:
> Any way I can help to get this commited? Should we add this to the commitfest?
Please do, it’s a good way to ensure that the patch is tracked and not
forgotten about.
cheers ./daniel
Hi,
Any way I can help to get this commited? Should we add this to the commitfest?
Regards,
--
Raúl Marín Rodríguez
carto.com
- works around pgbench command splitting on spaces,
if postgres sources are in a strangely named directory…
I tested within a directory named "pg .* dir".
I've also tested it with the initial case (including a +) and it works.
Good, thanks for checking!
--
Fabien.
Hi,
> - works around pgbench command splitting on spaces,
>if postgres sources are in a strangely named directory…
>I tested within a directory named "pg .* dir".
I've also tested it with the initial case (including a +) and it works.
--
Raúl Marín Rodríguez
carto.com
Hello Tom,
I did a little bit of googling on this subject last night, and it
seems that at least some people believe that the answer is to not
use glob, period, but read the directory for yourself.
As a short-term move to un-break the buildfarm, I'm just going to
revert that patch altogether.
On 1/21/19 11:18 AM, Fabien COELHO wrote:
>
> Hello Tom,
>
>> Well, glob does have some metacharacters, so not doing any quoting
>> at all still leaves us with failure modes.
>>
>> I did a little bit of googling on this subject last night, and it
>> seems that at least some people believe that th
Hello Tom,
Well, glob does have some metacharacters, so not doing any quoting
at all still leaves us with failure modes.
I did a little bit of googling on this subject last night, and it
seems that at least some people believe that the answer is to not
use glob, period, but read the directory
Hello Andrew,
About windows-specific issues, from File::Glob man page:
""" On DOSISH systems, backslash is a valid directory separator
character. In this case, use of backslash as a quoting character (via
GLOB_QUOTE) interferes with the use of backslash as a directory
separator. ... """
It se
Andrew Dunstan writes:
> Perhaps it would be OK we changed back the glob line to use $prefix
> instead of $qprefix, but kept the use of $qprefix in the later regex.
Well, glob does have some metacharacters, so not doing any quoting
at all still leaves us with failure modes.
I did a little bit of
On 1/21/19 4:50 AM, Fabien COELHO wrote:
>
> Hello Tom,
>
>> Hm, so bowerbird (a Windows machine) has been failing the pgbench tests
>> since this went in, cf
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01
>>
>>
>> I'm just guessing, but I sus
Hello Tom,
Hm, so bowerbird (a Windows machine) has been failing the pgbench tests
since this went in, cf
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01
I'm just guessing, but I suspect that bowerbird is using a path spec that
includes a backsl
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= writes:
>> Pushed with that correction.
> Thanks a lot!
Hm, so bowerbird (a Windows machine) has been failing the pgbench tests
since this went in, cf
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01
I'm
> Pushed with that correction.
Thanks a lot!
--
Raúl Marín Rodríguez
carto.com
I wrote:
> So the patch as given should work.
... well, modulo the use of "@foo" where you should've used "$foo".
I don't know enough Perl to understand why that seemed to work, but
I do know it's not the right thing here.
Pushed with that correction.
regards, tom lane
Alvaro Herrera writes:
>>> This does not look right to me: glob has a different set of special
>>> characters than regexes, no?
> Perhaps you can do
>@quoted = map { quotemeta($_) } @logs;
Actually, playing with it here, it seems that quotemeta() quotes
anything that's a special character fo
On 2019-Jan-18, Raúl Marín Rodríguez wrote:
> Hi,
>
> > Fun. But is that really the only place that fails?
>
> Yes, other than this it builds flawlessly.
>
> > This does not look right to me: glob has a different set of special
> > characters than regexes, no?
>
> The issue itself manifests i
Hi,
> Fun. But is that really the only place that fails?
Yes, other than this it builds flawlessly.
> This does not look right to me: glob has a different set of special
> characters than regexes, no?
The issue itself manifests in the grep call, not in glob, but I tried
using `quotemeta` only
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= writes:
> As mentioned in the subject, if the $PATH where you are building postgres
> contains a perl's special character [1], for example a `+`, pgbench's tap
> tests will fail.
Fun. But is that really the only place that fails?
> I'm attaching a pa
Hi,
As mentioned in the subject, if the $PATH where you are building postgres
contains a perl's special character [1], for example a `+`, pgbench's tap
tests will fail.
The outputs looks something like this (full at [2]):
```
# Failed test 'file name format'
# at t/001_pgbench_with_server.pl
22 matches
Mail list logo
