Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi
От | Andrew Dunstan |
---|---|
Тема | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi |
Дата | |
Msg-id | f62917d5-cc77-c6ac-847f-44f922ccdd97@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi
|
Список | pgsql-committers |
On 09/17/2018 10:48 AM, Tom Lane wrote: > 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. When you do I'll start a bowerbird run to check it. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-committers по дате отправления: