On 01/31/2014 06:19 PM, Bruce Momjian wrote:
> On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote:
>> On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
>>> Vik Fearing <vik.fearing@dalibo.com> writes:
>>>> Also worth mentioning is bug #7766.
>>>> http://www.postgresql.org/message-id/E1Tlli5-0007tR-HO@wrigleys.postgresql.org
>>> Yeah, did you read that whole thread? The real issue here is going to
>>> be whether client-side code falls over on wider-than-32-bit counts.
>>> We can fix the backend and be pretty sure that we've found all the
>>> relevant places inside it, but we'll just be exporting the issue.
>>> I did look at libpq and noted that it doesn't seem to have any internal
>>> problem, because it returns the count to callers as a string (!).
>>> But what do you think are the odds that callers are using code that
>>> won't overflow? I'd bet on finding atoi() or suchlike in a lot of
>>> callers. Even if they thought to use strtoul(), unsigned long is
>>> not necessarily 64 bits wide.
>> Application code that relies on the values already has problems though
>> since the returned values are pretty bogus now. Including the fact that
>> it can return 0 as the number of modified rows which is checked for more
>> frequently than the actual number IME...
>> So I think client code that uses simplistic stuff like atoi isn't worse
>> off afterwards since the values will be about as bogus. I am more
>> worried about code that does range checks like java's string conversion
>> routines...
>>
>> I think fixing this for 9.4 is fine, but due to the compat issues I
>> think it's to late for 9.3.
> Where are we on this? There was a posted patch, attached, but Vik
> Fearing said it was insufficent and he was working on a new one:
>
> http://www.postgresql.org/message-id/51EFF67A.7020509@dalibo.com
>
Unfortunately, I gave up on it as being over my head when I noticed I
was changing the protocol itself. I should have notified the list so
someone else could have taken over.
--
Vik