Subject: Re: Sometimes the output to the stdout in Windows disappears
To: pgsql-hackers@lists.postgresql.org
References: <ac976d8c-03df-d6b8-025c-15a2de8d9af1@postgrespro.ru>
 <4124040.1598898684@sss.pgh.pa.us>
From: Victor Spirin <v.spirin@postgrespro.ru>
Message-ID: <b92a7e09-9a60-d76b-e226-7e191fdc6f34@postgrespro.ru>
Date: Mon, 31 Aug 2020 22:38:36 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <4124040.1598898684@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: ru
Precedence: bulk

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
>
>