Re: Less than ideal error reporting in pg_stat_statements
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@heroku.com>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-02T21:29:38Z
Lists: pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes: > It would be nice to get this committed before the next point releases > are tagged, since I've now heard a handful of complaints like this. I'm not too impressed with this bit: /* Allocate buffer; beware that off_t might be wider than size_t */ - if (stat.st_size <= MaxAllocSize) + if (stat.st_size <= SIZE_MAX) buf = (char *) malloc(stat.st_size); because there are no, zero, not one uses of SIZE_MAX in our code today, and I do not see such a symbol required by the POSIX v2 spec either. Perhaps this will work, but you're asking us to introduce a brand new portability hazard just hours before a wrap deadline. That is not happening. Other than that, this seems roughly sane, though I've not read it in detail or tested it. Does anyone have an objection to trying to squeeze in something along this line? regards, tom lane
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