Re: pg_dump / copy bugs with "big lines" ?
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Craig Ringer <craig@2ndquadrant.com>,
Daniel Verite <daniel@manitou-mail.org>
Cc: Alvaro Herrera <alvherre@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-09-03T01:18:04Z
Lists: pgsql-hackers
On 09/03/2016 02:21 AM, Tomas Vondra wrote: > > A few minor comments regarding the patch: > > 1) CopyStartSend seems pretty pointless - It only has one function call > in it, and is called on exactly one place (and all other places simply > call allowLongStringInfo directly). I'd get rid of this function and > replace the call in CopyOneRowTo(() with allowLongStringInfo(). > > 2) allowlong seems awkward, allowLong or allow_long would be better > > 3) Why does resetStringInfo reset the allowLong flag? Are there any > cases when we want/need to forget the flag value? I don't think so, so > let's simply not reset it and get rid of the allowLongStringInfo() > calls. Maybe it'd be better to invent a new makeLongStringInfo() method > instead, which would make it clear that the flag value is permanent. > > 4) HandleParallelMessage needs a tweak, as it uses msg->len in a log > message, but with '%d' and not '%ld' (as needed after changing the type > to Size). > 5) The comment at allowLongStringInfo talks about allocLongStringInfo (i.e. wrong function name). regards -- Tomas Vondra http://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