Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi
Вложения
В списке pgsql-committers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: pgsql: Allow concurrent-safe open() and fopen() in frontend codefor Wi |
| Дата | |
| Msg-id | 20180917140202.GF31460@paquier.xyz обсуждение |
| Ответ на | 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 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
В списке pgsql-committers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера