Re: pg_dump / copy bugs with "big lines" ?
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Alvaro Herrera" <alvherre@2ndquadrant.com>
Cc: "Tomas Vondra" <tomas.vondra@2ndquadrant.com>,"Craig Ringer"
<craig@2ndquadrant.com>,"Tom Lane" <tgl@sss.pgh.pa.us>,"Robert Haas"
<robertmhaas@gmail.com>,"Jim Nasby" <Jim.Nasby@bluetreble.com>,"Ronan
Dunklau" <ronan.dunklau@dalibo.com>,"pgsql-hackers"
<pgsql-hackers@postgresql.org>
Date: 2016-12-05T09:57:24Z
Lists: pgsql-hackers
Attachments
- enlargestrinfo-fix.diff (text/x-patch) patch
Alvaro Herrera wrote: > I have now pushed this to 9.5, 9.6 and master. It could be backpatched > to 9.4 with ease (just a small change in heap_form_tuple); anything > further back would require much more effort. > > I used a 32-bit limit using sizeof(int32). I tested and all the > mentioned cases seem to work sanely; if you can spare some more time to > test what was committed, I'd appreciate it. My tests are OK too but I see an issue with the code in enlargeStringInfo(), regarding integer overflow. The bit of comment that says: Note we are assuming here that limit <= INT_MAX/2, else the above loop could overflow. is obsolete, it's now INT_MAX instead of INT_MAX/2. There's a related problem here: newlen = 2 * str->maxlen; while (needed > newlen) newlen = 2 * newlen; str->maxlen is an int going up to INT_MAX so [2 * str->maxlen] now *will* overflow when [str->maxlen > INT_MAX/2]. Eventually it somehow works because of this: if (newlen > limit) newlen = limit; but newlen is wonky (when resulting from int overflow) before being brought back to limit. PFA a minimal fix. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
Commits
-
Fix overflow check in StringInfo; add missing casts
- 42f50cb8fa98 10.0 landed
-
Permit dump/reload of not-too-large >1GB tuples
- fa2fa9955280 10.0 landed
- 646655d264f1 9.5.6 landed
- 4e01ecae9827 9.6.2 landed