Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUD3A-0003RV-QW for pgsql-hackers@arkaria.postgresql.org; Sun, 18 Oct 2020 18:04:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kUD39-0003Az-Np for pgsql-hackers@arkaria.postgresql.org; Sun, 18 Oct 2020 18:04:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUD39-0003AM-GX for pgsql-hackers@lists.postgresql.org; Sun, 18 Oct 2020 18:04:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUD37-0003v9-Fi for pgsql-hackers@lists.postgresql.org; Sun, 18 Oct 2020 18:04:54 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 09II4pOx229666; Sun, 18 Oct 2020 14:04:51 -0400 From: Tom Lane To: Alexander Lakhin cc: Victor Spirin , pgsql-hackers@lists.postgresql.org Subject: Re: Sometimes the output to the stdout in Windows disappears In-reply-to: References: <4124040.1598898684@sss.pgh.pa.us> <855416.1600022228@sss.pgh.pa.us> <4156857.1602865112@sss.pgh.pa.us> <117919.1602949857@sss.pgh.pa.us> <132799.1602960277@sss.pgh.pa.us> Comments: In-reply-to Alexander Lakhin message dated "Sun, 18 Oct 2020 21:00:00 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <229664.1603044291.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Oct 2020 14:04:51 -0400 Message-ID: <229665.1603044291@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alexander Lakhin writes: > With the fix all the 200 iterations passed as expected. > Then I ran the loop again just to be sure and got: > test thread/descriptor=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ... stderr FAILED=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 81 m= s > iteration 124 failed. Sigh ... still, this: > diff -w -U3 > .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr > .../src/interfaces/ecpg/test/results/thread-descriptor.stderr > --- .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr=C2=A0= =C2=A0=C2=A0 > 2019-12-04 16:05:46 +0300 > +++ .../src/interfaces/ecpg/test/results/thread-descriptor.stderr=C2=A0=C2= =A0=C2=A0 > 2020-10-18 20:20:27 +0300 > @@ -0,0 +1 @@ > +SQL error: descriptor "mydesc" not found on line 31 does not look like the same kind of failure as what we've been dealing with up to now. So maybe what we've got is that we fixed the stdio loss problem, and now the error rate is down to the point where we can notice other, even-lower-probability issues. regards, tom lane