Steve, The o_column column doesn't exist in 2.0 but did at one time prior to that. I'd guess you need to update the SQL API using rtpostgis_upgrade_20_minor.sql.
As for your second error, I believe that that error message is being kicked back from GDAL BUT it isn't the actual error that is causing the segfault. Please look at ticket #1782 as I think you're hitting that bug. I fixed that bug in r9649. You will want to try that revision instead. GDAL is correct when it responds saying that EPSG:105002 is not found as 105002 isn't a valid EPSG (epsg-registry.org). -bborie On 04/26/2012 08:50 AM, Stephen Crawford wrote: > OK, before I try to assemble all the data, a couple more questions. I > was finally able to access the logs and I see two errors: > > LOG: database system is ready to accept connections > LOG: autovacuum launcher started > ERROR: column "o_column" does not exist at character 39 > STATEMENT: select o_table_name, overview_factor, o_column, > o_table_schema from raster_overviews where r_table_schema = 'public' and > r_table_name = > 'spring_ms' and r_column = 'rast' > ERROR 6: EPSG PCS/GCS code 105002 not found in EPSG support files. Is > this a valid > EPSG coordinate system? > LOG: server process (PID 5497) was terminated by signal 11: > Segmentation fault > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > > > > For the first error, there is indeed no column "o_column" in the > raster_overviews table. There are also no records in the table it at > his point. > > For the second error "code 105002 not found in EPSG support files", > this projection is one I created to match the grids we use. I inserted > the definition in spatial_ref_sys. It is also listed in the > raster_columns and geometry_columns tables Is there somewhere else I > need to define it? I have used this projection in postgis for at least > 4 years now. > > I also noted that topology is not installed, if that matters at all. > > postgres 8.4.9 > > > postgis_full_version > ---------------------------------------------------------------------------------------------------------------------------------------- > > POSTGIS="2.0.0 r9605" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 > September 2009" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.7.6" > LIBJSON="UNKNOWN" RASTER > > Thanks again, > Steve > > > > On 4/25/2012 5:05 PM, Paul Ramsey wrote: >> In order to fix a problem, developers must reproduce it. What do we >> need to reproduce it: the offending SQL and the data itself. In ideal >> test cases the users can embed the data statically into a single SQL >> statement. In others they provide minimal versions of the offending >> tables. Try to make reproducing the problem as easy as possible for >> others, and the odds of it being fixed go up. Create a ticket with the >> SQL and description and attach your data to it. >> <http://trac.osgeo.org/postgis> >> >> P. >> >> On Wed, Apr 25, 2012 at 1:29 PM, Stephen Crawford<src...@psu.edu> wrote: >>> Well I tried the same query for just one of the tiles that I know >>> intersects >>> the the_geom but it crashed. Then i simplified it further by using >>> just a >>> box instead of a multipolygon and it still crashed. >>> >>> >>> On 4/25/2012 3:22 PM, Paul Ramsey wrote: >>>> Find the exact geometry pair that is causing the crash and file a >>>> ticket. (Yes, disconnecting means the backend went boom, that's a >>>> crash). >>>> P >>>> >>>> On Wed, Apr 25, 2012 at 12:15 PM, Stephen >>>> Crawford<src...@psu.edu> wrote: >>>>> All, >>>>> >>>>> I have a query which works on my desktop Windows (postgis2.0 RC) but >>>>> crashes >>>>> on Linux (postgis2.0 official release). And by crash i mean >>>>> disconnects >>>>> me >>>>> from the server. >>>>> >>>>> INSERT INTO result_raster_table (observation_date, rast) >>>>> SELECT r.observation_date, ST_Clip(r.rast,g.the_geom,-9999) AS rast >>>>> FROM raster_table r, geom_table g >>>>> WHERE r.observation_date = '2012-03-09'; >>>>> >>>>> 'raster_table ' holds tiles, 187 of which make up one >>>>> observation_date, >>>>> and >>>>> 'geom_table' is just one record, the union of ~23 Eastern US states. >>>>> >>>>> Any thoughts? >>>>> >>>>> Thanks, >>>>> Steve >>>>> >>>>> -- >>>>> Stephen Crawford >>>>> Center for Environmental Informatics >>>>> The Pennsylvania State University >>>>> src...@psu.edu >>>>> 814.865.9905 >>>>> >>>>> >>>>> _______________________________________________ >>>>> postgis-users mailing list >>>>> postgis-users@postgis.refractions.net >>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users >>>> _______________________________________________ >>>> postgis-users mailing list >>>> postgis-users@postgis.refractions.net >>>> http://postgis.refractions.net/mailman/listinfo/postgis-users >>> >>> -- >>> Stephen Crawford >>> Center for Environmental Informatics >>> The Pennsylvania State University >>> src...@psu.edu >>> 814.865.9905 >>> >>> >>> _______________________________________________ >>> postgis-users mailing list >>> postgis-users@postgis.refractions.net >>> http://postgis.refractions.net/mailman/listinfo/postgis-users >> _______________________________________________ >> postgis-users mailing list >> postgis-users@postgis.refractions.net >> http://postgis.refractions.net/mailman/listinfo/postgis-users > -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkp...@ucdavis.edu _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
