Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i608K-0005cd-0a for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 22:21:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i608I-0000xy-C9 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Sep 2019 22:21:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i608H-0000gc-Bs for pgsql-hackers@lists.postgresql.org; Thu, 05 Sep 2019 22:21:38 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i6088-0005st-Pm for pgsql-hackers@postgresql.org; Thu, 05 Sep 2019 22:21:36 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 5E877ECE; Thu, 5 Sep 2019 18:21:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 05 Sep 2019 18:21:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=Td2xsJz4JRz6qYf7chS/8b4qk/MhKfPAKpOChsJq1DM=; b=KljwEZn/ RgbnMuKY/KUNs2XU+1yk9qkkkH5FXwAgFZUjeZiOPlPUDyvW6IsH+k3krEV0gwbS utkf35rG9YyG9uokVh6qi75uMSDq1TnxI8MBZblwgGJsKvQBscZhZxdXQeVERewt Sm0r3Rl4twa64PLhvEJ3iweUnG3DIgZwyU6dlETXsbsmSCj9VPVeiyyziJ7x/cTn +Ezi9pb65228N4MmvucewfzN9x3b9/lWtziwopKxu+NckrXzGcEQC9ayFjR9O+d+ pVy/8jMIC5autsyNhTS0622DtJepribTfPaXHUBNqBbO4Nh4aEmiflPqT0ymVYSc dV75u5YB0GhfIQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejkedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruchfrhhomhcuvdhnugfsuhgrughrrghnthcuoegrlhhvhhgvrh hrvgesrghlvhhhrdhnohdqihhprdhorhhgqeenucffohhmrghinhepvdhnughquhgrughr rghnthdrtghomhenucfkphepudeltddruddvuddrvdelrdefnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: from nimloth.alvh.no-ip.org (unknown [190.121.29.3]) by mail.messagingengine.com (Postfix) with ESMTPA id 398EFD60067; Thu, 5 Sep 2019 18:21:25 -0400 (EDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id D8F98120BB0; Thu, 5 Sep 2019 18:21:22 -0400 (-04) Date: Thu, 5 Sep 2019 18:21:22 -0400 From: Alvaro Herrera from 2ndQuadrant To: "Iwata, Aya" Cc: "pgsql-hackers@postgresql.org" , "tgl@sss.pgh.pa.us" , "robertmhaas@gmail.com" , "pchampion@pivotal.io" , "jdoty@pivotal.io" , "raam.soft@gmail.com" , "Nagaura, Ryohei" , "nagata@sraoss.co.jp" , "kommi.haribabu@gmail.com" , "peter.eisentraut@2ndquadrant.com" , 'Kyotaro HORIGUCHI' , "Jamison, Kirk" Subject: Re: libpq debug log Message-ID: <20190905222122.GA29713@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <71E660EB361DF14299875B198D4CE5423DFBBFCB@g01jpexmbkw25> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello, Nice patch. I think there's pretty near consensus that this is something we want, and that the output format of one trace msg per libpq msg is roughly okay. (I'm not sure there's 100% agreement on this last point, but it seems close enough.) > I changed like this: > > 2019-04-04 02:39:51.488 UTC > Query 59 "SELECT pg_catalog.set_config('search_path', '', false)" The "59" there seems quite odd, though. * What is this in pg_conn? I don't understand why this array is of size MAXPGPATH. + PGFrontendLogMsgEntry frontend_entry[MAXPGPATH]; This seems to make pg_conn much larger than we'd like. Minor review points: * Do we need COMMAND_B_MIN etc to reduce the number of zeroes at the beginning of the tables? * The place where you define TRACELOG_TIME_SIZE seems like it'll be unavoidably out of date if somebody changes the format string. I'd put that #define next to where the fmt appears. * "output a a null-terminated" has duplicated "a" * We don't add braces around single-statement blocks (pqPutMsgEnd) * Please pgindent. Thanks -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services