Any ETA on 1.5.5? This bug in 1.5.4 is actually a show stopper for me... Thanks.
On 2012-07-10, at 10:46 PM, Paul Ramsey wrote:
On Tue, Jul 10, 2012 at 12:24 PM, Sandro Santilli s...@keybit.net wrote:
Better cut a 1.5.5 soon.
Did the NEWS file contain a note about this already ?
No, it was
Ticket submitted:
http://trac.osgeo.org/postgis/ticket/1903
But the crash problem seems not to happen for everyone. At least, the attached
SQL file will crash my PostgreSQL 1.5.4 on Mac OS X 10.7.4 every time. But not
for Paul. Would some of you be able to test it on your setup, to see
Ticket submitted:
http://trac.osgeo.org/postgis/ticket/1903
But the crash problem seems not to happen for everyone. At least, the
attached SQL file will crash my PostgreSQL 1.5.4 on Mac OS X 10.7.4 every
time. But not for Paul. Would some of you be able to test it on your setup,
Hi,
no problem with :
POSTGIS=1.5.2 GEOS=3.2.2-CAPI-1.6.2 PROJ=Rel. 4.6.1, 21 August 2008
LIBXML=2.7.6 USE_STATS
POSTGIS=1.5.3 GEOS=3.3.3-CAPI-1.7.4 PROJ=Rel. 4.6.1, 21 August 2008
LIBXML=2.7.8 USE_STATS
POSTGIS=2.0.0 r9605 GEOS=3.3.3-CAPI-1.7.4 PROJ=Rel. 4.8.0, 6 March
2012 GDAL=GDAL 1.9.0,
Nicolas: could you update the ticket with this indication ?
Sounds like a regression introduced by 1.5.4 : can you reproduce
consistently with that setup ?
--strk;
On Tue, Jul 10, 2012 at 02:06:43PM +0200, Nicolas Ribot wrote:
Ticket submitted:
Hi Sandro,
I will complete the ticket.
Reproducing consistently: not sure how to proceed, but I tested on 2
different databases (same PG version): one freshly created with pgis
1.5.4, one that did not contain postgis but contained several tables.
Then postgis was added to this DB and the test
Since others get crashes on 1.5.4, I tested *exactly* that version and
lo, it does in fact crash. The current 1.5 stable branch does not
crash, so finding the different might not be hard... (also points to
needing a 1.5.5)
P.
On Tue, Jul 10, 2012 at 1:00 AM, René Fournier m...@renefournier.com
Indeed, there has been a small change since 1.5.4 that moves some
testing for unknowns *below* the null test (where they should be)
avoiding the null pointer reference that is causing the crash.
Index: postgis/geography_gist.c
===
Better cut a 1.5.5 soon.
Did the NEWS file contain a note about this already ?
--strk;
On Tue, Jul 10, 2012 at 09:53:56AM -0700, Paul Ramsey wrote:
Indeed, there has been a small change since 1.5.4 that moves some
testing for unknowns *below* the null test (where they should be)
avoiding the
On Tue, Jul 10, 2012 at 12:24 PM, Sandro Santilli s...@keybit.net wrote:
Better cut a 1.5.5 soon.
Did the NEWS file contain a note about this already ?
No, it was a teeny change that had no ticket :) I know, I'm bad. Has one now.
P.
--strk;
On Tue, Jul 10, 2012 at 09:53:56AM -0700, Paul
Hi Paul,
Just submitted a ticket as you suggested:
http://trac.osgeo.org/postgis/ticket/1903
Thanks!
On 2012-07-04, at 11:46 PM, Paul Ramsey wrote:
This is all well and good, but we need to know which 300 rows to load.
If you have a load file, just strip out the first 301 (or whatever)
I've narrowed the point at which a crash will always happen: If I simply create
the table *without* the index...
CREATE INDEX address_location ON addresses USING GIST (location);
...it won't crash. (Inserts thousands of rows without a problem.) With that
index in place, it will always
This is all well and good, but we need to know which 300 rows to load.
If you have a load file, just strip out the first 301 (or whatever)
rows, confirm that the file makes things go boom and then create a
ticket on the tracker with the dump file attached.
http://trac.osgeo.org/
Thanks!
P.
On
Well, I did some more testing, and found out that the failed query and
subsequent crash of the postgresql client isn't caused by the lat/lng
coordinates... It happens consistently after a certain number of rows (and/or
amount of data) is inserted into the table. Usually close to 300 rows (or
On 03/07/12 12:34, René Fournier wrote:
Well, I did some more testing, and found out that the failed query and
subsequent crash of the postgresql client isn't caused by the lat/lng
coordinates... It happens consistently after a certain number of rows
(and/or amount of data) is inserted into the
On 2012-07-03, at 1:43 PM, Mark Cave-Ayland wrote:
On 03/07/12 12:34, René Fournier wrote:
If I quit and restart psql, same error occurs. Only if I drop the table
can I insert more rows — but again, only up to around 300 rows or 100 kb
(not sure where the limit is)... So, it's not
So, it seems that the table gets full and corrupted to some extent. After my
import script inserts ~290 rows, and then postgres crashes...
mydb=# select count(*) from addresses;INSERT INTO addresses ( account_id,
territory_id, location ) VALUES ( 1, 75, ST_GeomFromText('POINT(-114.267388
On 03/07/12 13:20, René Fournier wrote:
So, it seems that the table gets full and corrupted to some extent.
After my import script inserts ~290 rows, and then postgres crashes...
mydb=# select count(*) from addresses;INSERT INTO addresses (
account_id, territory_id, location ) VALUES (
18 matches
Mail list logo
