Tom Lane wrote: > I wrote: > > "Francisco Reyes" <lists@xxxxxxxxxxxxxxxx> writes: > >> On 3:09 pm 05/28/08 Gregory Stark <stark@xxxxxxxxxxxxxxxx> 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 <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
