I think sooner than later since it's a crasher in a fairly exercisable place.
P.
On Thu, Jul 12, 2012 at 12:59 AM, René Fournier wrote:
> 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, 201
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 wrote:
>> Better cut a 1.5.5 soon.
>> Did the NEWS file contain a note about this already ?
>
> No, it was a teeny
On Tue, Jul 10, 2012 at 12:24 PM, Sandro Santilli 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 Ramsey wrote
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 th
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
===
---
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 wrote:
> Ticket submitte
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 fil
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:
> >
> > http://trac.osgeo.org/postgis/ti
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 Marc
> 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 se
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
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)
> ro
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
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 c
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 (
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
51.089
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 no
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
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 96K
19 matches
Mail list logo
