From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: pgsql-committers@lists.postgresql.org,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code
 for Wi
In-reply-to: <20180917140202.GF31460@paquier.xyz>
References: <E1g0cYN-0003oE-IE@gemulon.postgresql.org>
 <23543.1536938575@sss.pgh.pa.us> <20180914224939.GA1178@paquier.xyz>
 <20180917114113.GA31460@paquier.xyz> <17194.1537191697@sss.pgh.pa.us>
 <20180917140202.GF31460@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Mon, 17 Sep 2018 23:02:02 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19654.1537195712.1@sss.pgh.pa.us>
Date: Mon, 17 Sep 2018 10:48:32 -0400
Message-ID: <19655.1537195712@sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Sep 17, 2018 at 09:41:37AM -0400, Tom Lane wrote:
>> Looking at the set of commits between the prior run and that one,
>> it's hard to see anything that could have triggered the test failures
>> other than this patch --- but I also don't see how this patch would've
>> blown up pgbench without breaking earlier tests.  Ideas?

> Thanks, I have been looking at the build farm but I missed this one.
> dory, which uses VS 2015 is not complaining because it does not run
> bincheck.  At quick glance, it seems to be caused by process_file() in
> pgbench.c which would need to open files in text mode, and the input
> file parsing fails at the first '\' character found.

Oh, you're thinking pgbench isn't robust against finding \r's visible
in its input?  Could be.

> I'll test that stuff on tomorrow morning manually.

We've got a bit of a timing problem because we want to wrap 11beta4/rc1
(still TBD) in a few hours.  I'll take a look and see if I can push a
quick fix before that.

			regards, tom lane