Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi
От | Tom Lane |
---|---|
Тема | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi |
Дата | |
Msg-id | 19655.1537195712@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: