Bill Thoen <bthoen@gisnet.com> writes:
> Is this what you need to see? (I attached GDB to the running postgres
> process and let it continue until it crashed, and then entered 'bt' and
> this is what I got.)
Hmm ... interesting but not conclusive. The most likely explanation
for this is corrupt data on-disk, but how it got that way is unclear.
Can you reproduce the problem if you import the same data into a new
table?
> Here's the backstory. The process that's crashing is an SQL update
> query on the table (corn0715). There are 104 fields in the table and the
> raw record length is about 648 characters. I have just imported it as a
> delimited file with COPY and there are about 1.7 million records.
Can we see the exact table declaration? I'm wondering if the table has
any columns of datatypes that are defined by the add-on modules.
> I compiled PostgreSQL 8.3.3, PostGIS 1.3.3, GEOS 3.0.0, Proj4 4.6.0 and
> GDAL 1.5.2 from source using gcc 4.3.0 on a newly installed Fedora Core
> 9 system. All software is the latest version and the disc drive was
> wiped clean before I started, so there are no old libraries or
> configurations lurking in the background.
> I did have some issues compiling GEOS, PostGIS and GDAL. Apparently,
> there have been some changes in gcc, particularly in the include files,
> and I was getting errors like 'memcpy' not declared, and the like. I
> fixed that (I think) with a diff patch, and everything seemed to compile
> and install OK.
This seems pretty suspicious to me. gcc 4.3 shouldn't have resulted in
any major changes in system header layout. What I am wondering is if
GEOS and GDAL have any direct dependencies on Postgres, and if so
whether they've been updated to work with 8.3.
regards, tom lane
