Re: Less than ideal error reporting in pg_stat_statements

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Less than ideal error reporting in pg_stat_statements
Date: 2015-10-05 15:27:40
Message-ID: 561296EC.805@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/05/2015 11:15 AM, Tom Lane wrote:
> Peter Geoghegan <pg(at)heroku(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-10-05 15:28:48 Re: Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older
Previous Message Alvaro Herrera 2015-10-05 15:16:05 Re: Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older