Segfault running ST_EstimatedExtent()

[brushtyler]

2012-01-27 16:12:40 CET LOG: statement: SELECT st_estimated_extent('city_data','face','mbr') AS extent; 2012-01-27 16:12:40 CET LOG: server process (PID 27986) was terminated by signal 11: Segmentation fault

where city_data is the sample dataset for topology.

[strk]

can you reproduce from the terminal ?

[brushtyler]

yes, the server crashes even running that query from psql.

Anyway the original query was:

test=> SELECT st_xmin(extent), st_ymin(extent), st_xmax(extent), st_ymax(extent) FROM (SELECT st_estimated_extent('city_data','face','mbr') AS extent) AS subquery;
The connection to the server was lost. Attempting reset: Failed.

instead running the query above I get:

test=> SELECT st_estimated_extent('city_data','face','mbr') AS extent;
The connection to the server was lost. Attempting reset: Succeeded.

[brushtyler]

I also get the same problem with other geometry tables, but I'm unable to find a common pattern.

[brushtyler]

I forgot to say that I'm on Ubuntu 11.04, PostgreSQL 8.4.10, PostGis? trunk r8942.

[strk]

select count(*) from city_data.face.mbr; -- please ?

[pramsey]

If you dump/restore the table, does the problem recur? (Because if so, dump the table so we can try it on our machines.)

[brushtyler]

Unable to restore the table...

psql:test/dump_test_1504.sql:7902: ERROR: SRID value 2097151 > SRID_MAXIMUM (999999) LINE 3: mbr public.geometry(Polygon,2097151)

I'm trying with the other tables I get the same error on.

[brushtyler]

Same problem also with other tables:

psql:test/dump_test_1504.sql:34: ERROR: SRID value 2097151 > SRID_MAXIMUM (999999) LINE 12: geom_event geometry(LineStringM,2097151)

[pramsey]

how did you get it in, in the first place then?

[brushtyler]

Before updating PostGIS to the latest trunk that query worked fine. Those tables was created before updating, so something is changed (maybe the MAX_SRID?) but I'm unable to say what revision I had had before.

[pramsey]

You can't just drop a 2.0 install on top of a 1.5 database, you *need* to dump and restore.

[strk]

You are restoring it _wrong_ , use postgis_restore.pl, see instructions in the postgis manual, under HARD UPGRADE.

[strk]

Wait a second, even if he restores the right way he would still have troubles restoring the _data_, wouldn't him ?

His only bet would be changing the SRIDs, can't not even drop the check from anywhere but touching the code. We should deal with this somehow.

[pramsey]

That's a different ticket, please open it, but leave this one closed! :)

[brushtyler]

I've found a way to reproduce it:

test=> CREATE TABLE "test_1504" (id int PRIMARY KEY, geom geometry(LineString,3003));
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_1504_pkey" for table "test_1504"
CREATE TABLE
test=> INSERT INTO "test_1504" (id, geom) VALUES (0, NULL);
INSERT 0 1
test=> ALTER TABLE "test_1504" ALTER COLUMN geom TYPE geometry(LineString, -1);
NOTICE:  SRID value -1 converted to the officially unknown SRID value 0
NOTICE:  SRID value -1 converted to the officially unknown SRID value 0
ALTER TABLE
test=> select st_estimated_extent('test_1504', 'geom');
The connection to the server was lost. Attempting reset: Failed.

NB: I tried to add with a geometry not NULL, but I got the same result (segfault).

After reconnecting and querying the table to get srid it returns a strange result:

test=> select st_srid(geom) from "test_1504";
 st_srid 
---------
        
(1 row)

I think that pg_dump now returns that strange (and maybe random) srid > MAX_SRID.

[brushtyler]

Replying to brushtyler:

After reconnecting and querying the table to get srid it returns a strange result: {{{ test=> select st_srid(geom) from "test_1504"; st_srid --------- (1 row) }}}

Obviously the srid is empty because the geometry is NULL...

[pramsey]

That's a winner, segfaults on me. Having a look.

[pramsey]

Being a bit more careful of NULL entries in the statistics table gets rid of the segfault. r8950