Re: Sometimes the output to the stdout in Windows disappears
От | Victor Spirin |
---|---|
Тема | Re: Sometimes the output to the stdout in Windows disappears |
Дата | |
Msg-id | b92a7e09-9a60-d76b-e226-7e191fdc6f34@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Sometimes the output to the stdout in Windows disappears (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Sometimes the output to the stdout in Windows disappears
|
Список | pgsql-hackers |
I only found that calling WSACleanup instead of PQfinish has the same effect. I don't see any big performance issues due to the extra fflush call in this place. I will be glad to find a more elegant solution. Victor Spirin Postgres Professional:http://www.postgrespro.com The Russian Postgres Company 31.08.2020 21:31, Tom Lane пишет: > Victor Spirin <v.spirin@postgrespro.ru> writes: >> Sometimes the output to stdout on Windows on multicore machines does not >> go through after connecting and disconnecting to the server using the >> PQconnectdbParams and PQfinish functions. I tested on 6 cores. > Hm, why is this not Microsoft's bug to solve? > > I do wonder if this report is related to the intermittent ecpg failures > we see on Windows machines, such as [1]. The details vary, but it's > always a case of a .stdout file ending up empty when it should not be. > I'd supposed though that it must be something specific to ecpg, since > we never see anything like that anywhere but the ecpg tests. Even if > you posit that libpq is doing something that somehow compromises stdio, > that should affect psql-based tests too. > >> I am attaching a patch and a script for testing. >> [ forced fflush in every snprintf call ] > My goodness, that's a large hammer you're swinging. What effects has this > kluge got on performance? > > While I think you may be on to something, this seems like a truly horrid > way to "fix" it. We need to dig down further and understand what is > actually happening. > > regards, tom lane > > [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2020-08-13%2022%3A15%3A05 > >
В списке pgsql-hackers по дате отправления: