Обсуждение: Abnormal termination of PostgreSQL

I recently installed Fedora Core 9 and included PostgreSQL, built form
source. I also built PostGIS, GEOS and GDAL to work with it. I had no
problems compiling and installing PostgreSQL, but I did have some
problems building GEOS and GDAL, although I think I've resolved those
(FC9 comes with gcc 4.3.0 which has had some changes that affect
building older source.) I'm using the latest versoin of everything.
PostgreSQL is ver 8.3.3.

Anyway, I created a database and "spatialized" it. Then created and
populated a table of about 1.7 million records that have no spatial
component. Then I ran an SQL update command to convert some double
precision columns to 1/100 and 1/10 of their original values. During
this update, about ten minutes into the operation (about when I expected
it would be done) the postgres server shuts down suddenly. It reports
this message:

vfm=> \i update.sql
psql:update.sql:1: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
psql:update.sql:1: connection to server was lost


Nothing very helpful is reported in the serverlog file except the
shutdown message.

In /var/log/messages I get:

Jun 21 10:42:57 sandbox kernel: postmaster[2534]: segfault at b8cfeabf
ip 08081357 sp bfb113c0 error 4 in postgres[8048000+335000]


I tried changing the SQL to only updating one field (e.g. 'update
corn0716 set average_yield = average_yield / 100 ;') and it also failed
in the same manner in about the same time (~10 minutes).

Does anyone know what happened and how I can fix it?

- Bill Thoen

Bill Thoen <bthoen@gisnet.com> writes:
> Does anyone know what happened and how I can fix it?

Well, you evidently hit a bug, but there's not nearly enough info here
to guess whether the bug is in Postgres, PostGIS, GEOS, or GDAL, or
perhaps in your custom build process for one of these.  I'd suggest
installing the debuginfo RPMs for them if you didn't already, collecting
a coredump (you'll need to ensure the postmaster is started with ulimit
-c unlimited) and getting a stack trace from the dump with gdb.
(Alternatively, since it takes awhile to reach the crash, you could just
attach to the running backend with gdb and let it continue to the crash;
that would save fooling with ulimit.)  Then send the trace to
pgsql-bugs.  You'll need to provide some details about the table and the
query, too.

            regards, tom lane