On Fri, Jun 25, 2021 at 06:12:09AM -0400, Andrew Dunstan wrote:
> + # On Msys, filter out any CRLF.
> + $contents_raw =~ s/\r\n/\n/g if $Config{osname} eq 'msys';
>
> This is completely redundant. The whole point is that slurp_file does
> exactly this for you.
Thanks. I have manage
On 6/24/21 11:08 PM, Michael Paquier wrote:
> On Thu, Jun 24, 2021 at 10:26:18PM -0400, Andrew Dunstan wrote:
>> Since the file isn't read in using slurp_file, that $ won't match
>> because the lines will end \r\n instead of \n.
> I did not remember this one with Msys, thanks. I am not sure that
On Thu, Jun 24, 2021 at 10:26:18PM -0400, Andrew Dunstan wrote:
> Since the file isn't read in using slurp_file, that $ won't match
> because the lines will end \r\n instead of \n.
I did not remember this one with Msys, thanks. I am not sure that
there is any need for an eval block here actually
On 6/24/21 10:12 PM, Andrew Dunstan wrote:
> On 6/24/21 9:53 PM, Michael Paquier wrote:
>> On Thu, Jun 24, 2021 at 09:36:53PM -0400, Andrew Dunstan wrote:
>>> That's not really an equivalent test. I'm taking a look
>> Thanks!
>
>
>
> There's a whole lot wrong with this code. To start with, why is
On 6/24/21 9:53 PM, Michael Paquier wrote:
> On Thu, Jun 24, 2021 at 09:36:53PM -0400, Andrew Dunstan wrote:
>> That's not really an equivalent test. I'm taking a look
> Thanks!
There's a whole lot wrong with this code. To start with, why is that
unchecked eval there. And why is it reading in
On Thu, Jun 24, 2021 at 09:36:53PM -0400, Andrew Dunstan wrote:
> That's not really an equivalent test. I'm taking a look
Thanks!
--
Michael
signature.asc
Description: PGP signature
On 6/24/21 8:26 PM, Michael Paquier wrote:
> (Forgot to add Andrew in CC, now done)
>
> On Fri, Jun 25, 2021 at 08:51:19AM +0900, Michael Paquier wrote:
>> Andrew, what's the format of the per-thread logs generated on this
>> host when running the commands? I'd bet that the checks for the
>> cli
(Forgot to add Andrew in CC, now done)
On Fri, Jun 25, 2021 at 08:51:19AM +0900, Michael Paquier wrote:
> Andrew, what's the format of the per-thread logs generated on this
> host when running the commands? I'd bet that the checks for the
> client IDs are right, but that some parts of the regex a
On Thu, Jun 24, 2021 at 09:54:51PM +, Michael Paquier wrote:
> Fix pattern matching logic for logs in TAP tests of pgbench
>
> The logic checking for the format of per-thread logs used grep() with
> directly "$re", which would cause the test to consider all the logs as
> a match without caring
Fix pattern matching logic for logs in TAP tests of pgbench
The logic checking for the format of per-thread logs used grep() with
directly "$re", which would cause the test to consider all the logs as
a match without caring about their format at all. Using "/$re/" makes
grep() perform a regex tes
Fix pattern matching logic for logs in TAP tests of pgbench
The logic checking for the format of per-thread logs used grep() with
directly "$re", which would cause the test to consider all the logs as
a match without caring about their format at all. Using "/$re/" makes
grep() perform a regex tes
Fix pattern matching logic for logs in TAP tests of pgbench
The logic checking for the format of per-thread logs used grep() with
directly "$re", which would cause the test to consider all the logs as
a match without caring about their format at all. Using "/$re/" makes
grep() perform a regex tes
Fix pattern matching logic for logs in TAP tests of pgbench
The logic checking for the format of per-thread logs used grep() with
directly "$re", which would cause the test to consider all the logs as
a match without caring about their format at all. Using "/$re/" makes
grep() perform a regex tes
13 matches
Mail list logo
