Re: BUG #17288: PSQL bug with COPY command (Windows)
От | Michael Paquier |
---|---|
Тема | Re: BUG #17288: PSQL bug with COPY command (Windows) |
Дата | |
Msg-id | YZdK6DjbtCT7rz9S@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #17288: PSQL bug with COPY command (Windows) (Dmitry Koval <d.koval@postgrespro.ru>) |
Ответы |
Re: BUG #17288: PSQL bug with COPY command (Windows)
|
Список | pgsql-bugs |
On Thu, Nov 18, 2021 at 09:48:55PM +0300, Dmitry Koval wrote: > >You are right about freopen(), but stderr works just because it's being > >parsed as a file, not a stream, by parse_slash_copy(). > > You are right. I wrote about stderr without inspecting code ( > > >I would keep the memset(buf, 0, sizeof(*buf)) for the members we > >are not setting. > > Of course. Original code (src/port/win32stat.c) contains line > > memset(buf, 0, sizeof(*buf)) > > before call GetFileInformationByHandle(). I still think that we should not call GetFileInformationByHandle() when it comes to an argument that we know will fail, so I would agree with Juan's approach in v2 to just patch _pgfstat64() rather than messing with the code paths in charge of checking handles pending for deletion. Each fileno is going to be 0, 1 or 2 in those cases, still it would be better to rely on the result of fileno() as v3 is doing? It looks like you are right about _S_IFCHR for st_mode, as of this part of the docs: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fstat-fstat32-fstat64-fstati64-fstat32i64-fstat64i32?view=msvc-170 -- Michael
Вложения
В списке pgsql-bugs по дате отправления: