Re: pg_dump / copy bugs with "big lines" ?
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Daniel Verite <daniel@manitou-mail.org>
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-09T14:51:41Z
Lists: pgsql-hackers
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 had to revert this on 9.5 and 9.6 -- it is obvious (in hindsight) that changing StringInfoData is an ABI break, so we can't do it in back branches; see https://www.postgresql.org/message-id/27737.1480993846@sss.pgh.pa.us The patch still remains in master, with the bugs you pointed out. I suppose if somebody is desperate about getting data out from a table with large tuples, they'd need to use pg10's pg_dump for it. We could use the highest-order bit in StringInfoData->maxlen to represent the boolean flag instead, if we really cared. But I'm not going to sweat over it ... -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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