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 1lRjOO-0001vk-Oa for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Mar 2021 22:32:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lRjON-0000Jl-MI for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Mar 2021 22:32:51 +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 1lRjNS-0005se-Fv for pgsql-hackers@lists.postgresql.org; Wed, 31 Mar 2021 22:31:54 +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 1lRjNQ-0003LX-A5 for pgsql-hackers@lists.postgresql.org; Wed, 31 Mar 2021 22:31:53 +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 12VMVjHQ3337423; Wed, 31 Mar 2021 18:31:45 -0400 From: Tom Lane To: "'alvherre@alvh.no-ip.org'" cc: "iwata.aya@fujitsu.com" , "tsunakawa.takay@fujitsu.com" , "'Kyotaro Horiguchi'" , "k.jamison@fujitsu.com" , "pgsql-hackers@lists.postgresql.org" , Andrew Dunstan Subject: Re: libpq debug log In-reply-to: <3336855.1617229186@sss.pgh.pa.us> References: <20210331220920.GA23882@alvherre.pgsql> <3336855.1617229186@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 31 Mar 2021 18:19:46 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3337421.1617229905.1@sss.pgh.pa.us> Date: Wed, 31 Mar 2021 18:31:45 -0400 Message-ID: <3337422.1617229905@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > What I suspect is some Windows dependency in the way that > 001_libpq_pipeline.pl is setting up the trace output files. While this may have little to do with drongo's issue, I'm going to take exception to this bit that I see that the patch added to PQtrace(): /* Make the trace stream line-buffered */ setvbuf(debug_port, NULL, _IOLBF, 0); I do not like that on two grounds: 1. The trace file handle belongs to the calling application, not to libpq. I do not think libpq has any business editorializing on the file's settings. 2. POSIX says that setvbuf() must be done before any other operation on the file. Since we have no way to know whether any output has already been written to the trace file, the above is a spec violation. ... and as for an actual explanation for drongo's issue, I'm sort of wondering why libpq_pipeline.c is opening the trace file in "w+" mode rather than vanilla "w" mode. That seems unnecessary, and maybe it doesn't work so well on Windows. regards, tom lane