Re: Sometimes the output to the stdout in Windows disappears

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Victor Spirin <v(dot)spirin(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Sometimes the output to the stdout in Windows disappears
Date: 2020-08-31 18:31:24
Message-ID: 4124040.1598898684@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Victor Spirin <v(dot)spirin(at)postgrespro(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-08-31 18:34:45 Re: LogwrtResult contended spinlock
Previous Message Pavel Stehule 2020-08-31 18:29:47 Re: Get memory contexts of an arbitrary backend process