Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Zj7Um-0006iP-66 for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Oct 2015 15:16:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1Zj7Ul-00040Z-Nk for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Oct 2015 15:16:07 +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_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zj7Ul-00040T-Cv for pgsql-hackers@postgresql.org; Mon, 05 Oct 2015 15:16:07 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zj7Ui-0003pa-4w for pgsql-hackers@postgresql.org; Mon, 05 Oct 2015 15:16:06 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id t95FFuT1030113; Mon, 5 Oct 2015 11:15:56 -0400 From: Tom Lane To: Peter Geoghegan cc: Jim Nasby , Pg Hackers Subject: Re: Less than ideal error reporting in pg_stat_statements In-reply-to: References: <5601D354.5000703@BlueTreble.com> <15898.1442965225@sss.pgh.pa.us> <56030E72.9070104@BlueTreble.com> Comments: In-reply-to Peter Geoghegan message dated "Sun, 04 Oct 2015 18:03:48 -0700" Date: Mon, 05 Oct 2015 11:15:56 -0400 Message-ID: <30112.1444058156@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Peter Geoghegan writes: > I'm annoyed and disappointed that the patch committed does not even > begin to address the underlying problem -- it just adds an escape > hatch, and fixes another theoretical issue that no one was affected > by. Honestly, next time I won't bother. The problem as I see it is that what you submitted is a kluge that will have weird and unpredictable side effects. Moreover, it seems to be targeting an extremely narrow problem case, ie large numbers of queries that (a) have long query texts and (b) are distinct to the fingerprinting code and (c) fail. It seems to me that you could get into equal trouble with situations where (c) is not satisfied, and what then? I'm certainly amenable to doing further work on this problem. But I do not think that what we had was well-enough-thought-out to risk pushing it just hours before a release deadline. Let's arrive at a more carefully considered fix in a leisurely fashion. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers