Re: BUG #2481: select from table's join with geometries doesn't go
От | Michael Fuhr |
---|---|
Тема | Re: BUG #2481: select from table's join with geometries doesn't go |
Дата | |
Msg-id | 20060616053607.GA8567@winnie.fuhr.org обсуждение исходный текст |
Ответ на | Re: BUG #2481: select from table's join with geometries doesn't go (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #2481: select from table's join with geometries doesn't go
|
Список | pgsql-bugs |
On Thu, Jun 15, 2006 at 11:48:37PM -0400, Tom Lane wrote: > "Emilia Venturato" <venturato@faunalia.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
В списке pgsql-bugs по дате отправления: