Re: Less than ideal error reporting in pg_stat_statements
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@heroku.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-05T15:27:40Z
Lists: 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
Commits
-
Be more wary about 32-bit integer overflow in pg_stat_statements.
- c67c2e2a2939 16.0 landed
- dd414bf4e047 10.22 landed
- 82ebc70d1c7f 15.0 landed
- 6b67db10c366 13.8 landed
- 6608a4305636 12.12 landed
- 17fd203b414e 14.5 landed
- 06f6a07ba465 11.17 landed