Re: Less than ideal error reporting in pg_stat_statements - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Less than ideal error reporting in pg_stat_statements
Date
Msg-id 20151005154032.GF8531@alvherre.pgsql
Whole thread Raw
In response to Re: Less than ideal error reporting in pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Less than ideal error reporting in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andrew Dunstan wrote:
> 
> On 10/05/2015 11:15 AM, Tom Lane wrote:
> >Peter Geoghegan <pg@heroku.com> 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?

> FWIW, (a) and (b) but not (c) is probably the right description for my
> client who has been seeing problems here.

I think the fact that long IN lists are fingerprinted differently
according to the number of elements in the list makes the scenario
rather very likely -- not particularly narrow.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older
Next
From: Oleksii Kliukin
Date:
Subject: run pg_rewind on an uncleanly shut down cluster.