Tom Lane wrote: > I wrote: > > "Francisco Reyes" <[EMAIL PROTECTED]> writes: > >> On 3:09 pm 05/28/08 Gregory Stark <[EMAIL PROTECTED]> wrote: > > Does it really have a COPY command at the beginning? Are you really doing > > >\i data/usb_t_60M.sql or were you trying to do a copy from this file? > > >> Argh..That's it. > >> When I re-organized the scripts I must have taken the copy command from > >> the top of the data file and did not put a 'copy from' in the calling > >> script. > > > Hmm ... even so, it shouldn't have crashed, it should at worst have > > given you an out-of-memory error message. > > Hmm, I see the problem: the pqexpbuffer code maxes out at INT_MAX bytes > in the string buffer, which would be all right except that it has no > good way to report the error and so the input is just getting truncated > at that length. But then what happens is that pqPuts computes > strlen(s) + 1, which is still all right because size_t is 64 bits > on this machine, and passes that to pqPutMsgBytes, which computes > conn->outMsgEnd + len *and smashes that to int*. So the value passed > to pqCheckOutBufferSpace is negative, and the latter falsely concludes > there's enough space in the buffer, and then the memcpy goes boom. > > A minimum solution would be to make pqCheckOutBufferSpace deal in > size_t not int, but I have a feeling there are a lot of other similar > gotchas when running this code on a 64-bit machine. We use int > arithmetic an awful lot for stuff that probably should be size_t > or ssize_t ...
I assume this is not a TODO item. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
