From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Taravudh Tipdecho <taravudh(at)hpcc(dot)nectec(dot)or(dot)th> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Problem with query length |
Date: | 1999-03-19 15:46:30 |
Message-ID: | 25641.921858390@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Taravudh Tipdecho <taravudh(at)hpcc(dot)nectec(dot)or(dot)th> writes:
> Our problem is with the insert command when we insert a large polygon
> (~200 points). With version 6.3 we have no problem inserting the
> polygon. In fact all the polygons were inserted, verifying that they
> were less than the 8K limit. However with version 6.4.2, the backend
> closes the connection during the insert.
> The first time we noticed this, we had a lot of trailing zeros on the
> values of the points and eliminating the zeros allowed a smaller polygon
> (that previously failed with ~ 170 points) to be inserted in version
> 6.4.2. This seems to indicate that there is some kind of limit on the
> length of the query string. Isolating the query string that failed
> indicates that the string is about 4500 bytes.
That's really odd; it's hard to believe that the maximum query length
got shorter.
I presume the backend dropped a corefile when it crashed; can you use
gdb on the corefile to provide a backtrace? Alternatively, can you
provide a fairly short psql script that demonstrates the problem?
(If you're right about the problem, just a CREATE TABLE and INSERT
oughta do it...) I will look into it if I can reproduce it here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas IZ5 | 1999-03-19 17:26:20 | portability patch |
Previous Message | Tom Lane | 1999-03-19 15:42:07 | Re: [HACKERS] Removing derived files from CVS |