Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-committers@lists.postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Date: 2018-09-17T14:02:02Z
Lists: pgsql-hackers
On Mon, Sep 17, 2018 at 09:41:37AM -0400, Tom Lane wrote:
> BTW, I'm a bit concerned by the fact that bowerbird has failed its
> last couple of HEAD runs at the pgbench step.  The first such
> failure was here:
> 
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2018-09-15%2014%3A19%3A58
> 
> 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.  I'll test that
stuff on tomorrow morning manually.
--
Michael

Commits

  1. Enforce translation mode for Windows frontends to text with open/fopen

  2. Fix pgbench lexer's "continuation" rule to cope with Windows newlines.

  3. Allow concurrent-safe open() and fopen() in frontend code for Windows