Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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)

postgis-1.5_9.0.zip (195.8 KB) - added by robe 10 years ago.
recomipiled windows dll to fix analyze bug

Download all attachments as: .zip

Change History (6)

comment:1 Changed 10 years ago by aperi2007

Hi,

The postgres guy find where the postgres crash.

( http://archives.postgresql.org/pgsql-bugs/2010-10/msg00042.php)

It's crashing in pfree, as called by examine_attribute here:

if (!ok
stats->compute_stats == NULL stats->minrows <= 0)

{

pfree(stats->attrtype); pfree(stats->attr); <-- crash pfree(stats); return NULL;

}

... which is palloc'd earlier in examine_attribute.

VC++ is having trouble examining the locals in examine_attribute(); I'm unsure if >this is an optimization issue, lack of full debug info, or something wrong with >the state of the stack.

It's definitely crashing while analyzing the relation "suolo" - not only do the >logs show analysis beginning, but onerel->rd_rel->relname is "suolo". At the time >of the crash it seems to have already added the column with attr->attname = >"codpoligono" to vacattrstats and is examining the column with attnum=5 when it >crashes. A quick look at pg_class and pg_attribute shows that this is (surprise!) >the "geom" column of type "geometry".

PostGIS on Windows is a bit outside my depth, especially as it's not a neat crash >in the analyze function its self. Hopefully this'll give the PostGIS folks >something to go on, though. Andrea: please pass it on.

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.

comment:2 Changed 10 years ago by mcayland

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?

Changed 10 years ago by robe

Attachment: postgis-1.5_9.0.zip added

recomipiled windows dll to fix analyze bug

comment:3 Changed 10 years ago by robe

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 Changed 10 years ago by aperi2007

Resolution: fixed
Status: newclosed

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 Changed 10 years ago by robe

Keywords: windows added
Milestone: PostGIS 1.5.3PostGIS 1.5.2
Note: See TracTickets for help on using tickets.