Skip site navigation (1) Skip section navigation (2)

Re: BUG #2481: select from table's join with geometries doesn't go

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Emilia Venturato <venturato(at)faunalia(dot)it>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2481: select from table's join with geometries doesn't go
Date: 2006-06-16 05:36:08
Message-ID: 20060616053607.GA8567@winnie.fuhr.org (view raw or flat)
Thread:
Lists: pgsql-bugs
On Thu, Jun 15, 2006 at 11:48:37PM -0400, Tom Lane wrote:
> "Emilia Venturato" <venturato(at)faunalia(dot)it> writes:
> > Postgis developper said it could be a postgresql bug.
> 
> Or it could be a postgis bug.  Without a test case we can use to
> reproduce the problem, it's all speculation.  Please send a complete,
> self-contained test case...

This report resembles a message Emilia posted in postgis-users a
couple of weeks ago.  The only public discussion is a request for
the PostGIS version and copy of the data:

http://postgis.refractions.net/pipermail/postgis-users/2006-June/012281.html
http://postgis.refractions.net/pipermail/postgis-users/2006-June/012282.html

Emilia, did you and Sandro (strk) have off-list discussion about
this problem?  What do version() and postgis_full_version() return?
What happens if you select the geometry column without a join, i.e.,
"SELECT the_geom FROM wwf_terr_ecos_multigeom WHERE ..."?  Do you
get the segmentation fault with the original query if you select
AsText(the_geom) or AsEWKT(the_geom) instead of just the_geom?

Did the segmentation fault leave a core dump in your $PGDATA directory
or somewhere beneath it?  If not then you might need to adjust your
coredumpsize resource limit.

-- 
Michael Fuhr

In response to

Responses

pgsql-bugs by date

Next:From: Devrim GUNDUZDate: 2006-06-16 06:04:21
Subject: Re: BUG #2480: Installation Error of RMP for RHEL4
Previous:From: Tom LaneDate: 2006-06-16 04:05:10
Subject: Re: BUG #2482: Wrong result in timestamp_in, timestamptz_in, date_in

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group