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 1l6wYE-0006LQ-Li for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Feb 2021 14:21:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l6wYD-0002za-I1 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Feb 2021 14:21:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l6wYC-0002zS-M5 for pgsql-hackers@lists.postgresql.org; Tue, 02 Feb 2021 14:21:05 +0000 Received: from [66.111.4.27] (helo=out3-smtp.messagingengine.com) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l6wY8-0001Es-LC for pgsql-hackers@lists.postgresql.org; Tue, 02 Feb 2021 14:21:04 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C501C5C02DA; Tue, 2 Feb 2021 09:20:48 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 02 Feb 2021 09:20:48 -0500 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= fm2; bh=v2B1VcZA2M3unLWZQnDMA6sOB9jvi7eVROdeUcinEEY=; b=WhGICyPH 0R+/WPPHiFAhBwk/I/cc1CyWJLoci58dcZHMYAJQFEQ+dQqhSxchtjW59I/CZbX5 WChqQOolqqxRWgSlp0yRfkqzVaRXnoTP5ok8kzhVGp9xwKFsvV4EdtTT3RS1bimi h2sI0Af1NtoQyF2bTH49Ptg6WH8f5rAfKN3rZZiNeFQDiP7nb22Ivitoma6osR9y UBMXIr1mQRWM6WpyHtACzaE4Gb8xILIjzrOLM6yC6naLhVlEBkHSu9j5/DRdgBjy uoiHHtFo1kvOxPKUaq7zWN/cn8Menvc+tzuEXAk1uSBZF9Sil1lg8B3NVh+UL4gZ T+dUcGtlIacatg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgedtgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggugfgjfgesthekre dttderudenucfhrhhomhepkdetlhhvrghrohcujfgvrhhrvghrrgdkuceorghlvhhhvghr rhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhepgfdvvedvte eiheevgfeltdetgffghfeghedvleehvdetiedthffgjeegkeekjeeknecukfhppeduledt rdelhedrudelrddujeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.177]) by mail.messagingengine.com (Postfix) with ESMTPA id CD1281080067; Tue, 2 Feb 2021 09:20:47 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 314612A0C92; Tue, 2 Feb 2021 11:20:45 -0300 (-03) Date: Tue, 2 Feb 2021 11:20:45 -0300 From: 'Alvaro Herrera' To: "tsunakawa.takay@fujitsu.com" Cc: "k.jamison@fujitsu.com" , "iwata.aya@fujitsu.com" , "'pgsql-hackers@lists.postgresql.org'" Subject: Re: libpq debug log Message-ID: <20210202142045.GA13771@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Host-Lookup-Failed: Reverse DNS lookup failed for 66.111.4.27 (deferred) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-Jan-29, tsunakawa.takay@fujitsu.com wrote: > (30) > +/* > + * Deallocate FE/BE message tracking memory. We only do this because > + * FE message can grow arbitrarily large, and skip it in the initial state, > + * because it's likely pointless. > + */ > +void > +pqTraceUninit(PGconn *conn) > +{ > + if (conn->fe_msg && > + conn->fe_msg->num_fields != DEF_FE_MSGFIELDS) > + { > + free(conn->fe_msg); > + conn->fe_msg = NULL; > + } > > What does the second if condition mean? If it's not necessary, change the comment accordingly. The rationale for that second condition is this: if the memory allocated is the initial size, we don't free memory, because it would just be allocated of the same size next time, and that size is not very big, so it's not a big deal if we just let it be, so that it is reused if we call PQtrace() again later. However, if the allocated size is larger than default, then it is possible that some previous tracing run has enlarged the trace struct to a very large amount of memory, and we don't want to leave that in place. -- Álvaro Herrera Valdivia, Chile