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