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 1h17L9-0006S0-Qd for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Mar 2019 10:30:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h17L8-0004ho-CB for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Mar 2019 10:30:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h17L7-0004hV-TZ for pgsql-hackers@lists.postgresql.org; Tue, 05 Mar 2019 10:30:26 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h17L3-0007aL-9C for pgsql-hackers@postgresql.org; Tue, 05 Mar 2019 10:30:24 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 89C6E21CB606; Tue, 5 Mar 2019 13:30:18 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.237] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 5C51621CB5EE; Tue, 5 Mar 2019 13:30:18 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1551781818; bh=49riSScV4pnpVB2IH+8mEOKMS9P9HIyaLHLvKEwz7Kg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=gEdgCl0lthgIXqke9r5VA5NC243rcVg7RpbT2ItqhHGpHLqMWv7ytlGAXMiYfIqZv 9rAOlveO6oPTBBzWRmCCF1VfB/pqkh8mfW1aRTbH6q71GB3VV/lNwAfZrZRgwVYxnf +4bzi5j8qNSqE+dWFjJjJPDcRCDTC2wmqqSg+G6k= Subject: Re: query logging of prepared statements To: Justin Pryzby Cc: pgsql-hackers@postgresql.org References: <20190208132953.GF29720@telsasoft.com> <20190215145704.GW30291@telsasoft.com> <20190227180653.GF28750@telsasoft.com> <70868e0d-2a29-36c8-e3e2-f54a56804bc4@postgrespro.ru> <20190304183150.GK29584@telsasoft.com> From: Arthur Zakirov Message-ID: <345f3504-e3cd-3a01-c593-ebbbe555dd69@postgrespro.ru> Date: Tue, 5 Mar 2019 13:30:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190304183150.GK29584@telsasoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 04.03.2019 21:31, Justin Pryzby wrote: > It wasn't intentional. Find attached v3 patch which handles that case, > by removing the 2nd call to errdetail_execute() ; since it's otherwise unused, > so remove that function entirely. Thank you. > Thanks for reviewing. I'm also interested in discussion about whether this > change is undesirable for someone else for some reason ? For me, the existing > output seems duplicative and "denormalized". :) I perfectly understand your use case. I agree, it is duplicated. But I think some people may want to see it at every EXECUTE, if they don't want to grep for the prepared statement body which was logged earlier. I think it would be good to give possibility to configure this behavior. At first version of your patch you relied on log_error_verbosity GUC. I'm not sure that this variables is suitable for configuring visibility of prepared statement body in logs, because it sets more general behavior. Maybe it would be better to introduce some new GUC variable if the community don't mind. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company