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@xxxxxxxxxx> writes: >>>> Also worth mentioning is bug #7766. >>>> http://www.postgresql.org/message-id/E1Tlli5-0007tR-HO@xxxxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxx > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
