Less than ideal error reporting in pg_stat_statements
Jim Nasby <jim.nasby@bluetreble.com>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2015-09-22T22:16:52Z
Lists: pgsql-hackers
Attachments
- patch.diff (text/plain) patch
A client was getting some hard to diagnose out of memory errors. What made this especially confusing was that there was no context reported at all, other than the (enormous) statement that triggered the error. At first I thought the lack of context indicated a palloc had failed during ereport() (since we apparently just toss the previous error when that happens), but it turns out there's some error reporting in pg_stat_statements that's less than ideal. Attached patch fixes, though I'm not sure if %lld is portable or not. I'll also argue that this is a bug and should be backpatched, but I'm not hell-bent on that. At the same time I looked for other messages that don't explicitly reference pg_stat_statements; the only others are in pg_stat_statements_internal() complaining about being called in an inappropriate function context. Presumably at that point there's a reasonable error context stack so I didn't bother with them. This still seems a bit fragile to me though. Anyone working in here has to notice that most every errmsg mentions pg_stat_statements and decide there's a good reason for that. ISTM it'd be better to push a new ErrorContextCallback onto the stack any time we enter the module. If folks think that's a good idea I'll pursue it as a separate patch. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
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