#619 closed defect (fixed)
Postgres 9.0 with Postgis 1.5.2 crash on windows on this query
Reported by: | aperi2007 | Owned by: | pramsey |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 1.5.2 |
Component: | postgis | Version: | 1.5.X |
Keywords: | windows | Cc: |
Description
On Postres 9.0 with postgis 1.5.2 and Windows 7 (32bit/64bit)
setting autovacuum = off and executing this query:
SELECT DropGeometryColumn('public','poslist','geom'); DROP TABLE IF EXISTS poslist; SELECT DropGeometryColumn('public','suolo','geom'); DROP TABLE IF EXISTS suolo; SELECT DropGeometryColumn('public','linee_elementari','geom'); DROP TABLE IF EXISTS linee_elementari; CREATE TABLE SUOLO (CODPOLIGONO VARCHAR(35) PRIMARY KEY, CODCLASSE VARCHAR(35), CODORIGINESUOLO VARCHAR(35), TAGNO INTEGER ); SELECT AddGeometryColumn( 'public','suolo', 'geom',3003, 'POLYGON', 2 ); alter table suolo add column oid serial not null; CREATE TABLE POSLIST (ID VARCHAR(35) PRIMARY KEY, IDLINESTRING VARCHAR(35), POSLIST VARCHAR(200000), LUNG_POSLIST INTEGER, NUM_VERTEX INTEGER , DIMENSION VARCHAR(1) ); SELECT AddGeometryColumn( 'public','poslist', 'geom',3003, 'LINESTRING', 2 ); alter table poslist add column oid serial not null; CREATE TABLE LINEE_ELEMENTARI (CODLINEA VARCHAR(35) PRIMARY KEY, CODCTR VARCHAR(35), CODVISIBILITA VARCHAR(35), CODBREAKLINE VARCHAR(35), CODCLASSE VARCHAR(35), CODLATOVESTIZIONE VARCHAR(35), CODORIGINELINEA VARCHAR(35), CODMODIFICA VARCHAR(35), POSLIST VARCHAR(200000), LUNG_POSLIST INTEGER, NUM_VERTEX INTEGER, IDEDGE VARCHAR(35), SRSNAME VARCHAR(35), DIMENSION VARCHAR(1), COORD_N1 VARCHAR(50), COORD_N2 VARCHAR(50) ); SELECT AddGeometryColumn( 'public','linee_elementari', 'geom',3003, 'LINESTRING', 2 ); alter table linee_elementari add column oid serial not null;
If after the execution of the query I run this two commands: vacuum; analyze;
the PG9 crash.
The same query work without any problems on PG8.4.4 + postgis 1.5.2
(bug reported even to pgsql-bugs ML) http://archives.postgresql.org/pgsql-bugs/2010-10/msg00031.php
Attachments (1)
Change History (6)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Yes, that's probably the cause of it.
I did a few tests with PostgreSQL 9.0 git pulls here when reviewing the patch for 9.0 (i.e. load several shapefiles, VACUUM ANAYZE) and it didn't cause problems for me, so I must have somehow missed triggering this
We need to make sure that the resulting fix works both on 8.3 and 9.0 aswell - so perhaps some #ifdef-ery is required?
comment:3 by , 14 years ago
Andrea, I think this may be just a packaging mistake on our fault and no additional code changes may be required. As suggested in one of the above pg bug posts, we had compiled against postgresql-9.0 RC1 instead of the RTM version. Recompiling postgis 1.5.2 against the postgresql-9.0 source code official release, makes your test case not crash anymore for us.
Can you replace your postgis-1.5.dll with the attached version and see if that fixes your issue?
Thanks, Regina and Leo
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Hi,
I have tested the new version of postgis5.dll.
With this new version the crash is disappear
Really good !
I have reported the solution to pgsql-bugs ML.
Thx for great support.
Andrea.
comment:5 by , 14 years ago
Keywords: | windows added |
---|---|
Milestone: | PostGIS 1.5.3 → PostGIS 1.5.2 |
Hi,
The postgres guy find where the postgres crash.
( http://archives.postgresql.org/pgsql-bugs/2010-10/msg00042.php)
They ask if there some relation with a last-minute correction of postgres).
http://archives.postgresql.org/pgsql-bugs/2010-10/msg00043.php
Regards, Andrea.