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

From Andrew Dunstan
Subject Re: Less than ideal error reporting in pg_stat_statements
Date
Msg-id 561296EC.805@dunslane.net
Whole thread Raw
In response to Re: Less than ideal error reporting in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Less than ideal error reporting in pg_stat_statements  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers

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?
>
> 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.
>
>             


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

cheers

andrew



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: Andres Freund
Date:
Subject: Re: Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older