Re: Less than ideal error reporting in pg_stat_statements
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@heroku.com>,
Jim Nasby <Jim.Nasby@bluetreble.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-05T15:40:32Z
Lists: 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
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