BUG #5436: PostGIS 1.5.1 causing postmaster 8.3 crash on index creation

From: "Nick Bower" <nick(at)petangent(dot)net>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #5436: PostGIS 1.5.1 causing postmaster 8.3 crash on index creation
Date: 2010-04-23 11:03:25
Message-ID: 201004231103.o3NB3Pia098069@wwwmaster.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


The following bug has been logged online:

Bug reference: 5436
Logged by: Nick Bower
Email address: nick(at)petangent(dot)net
PostgreSQL version: 8.3 + 8.4
Operating system: Windows XP
Description: PostGIS 1.5.1 causing postmaster 8.3 crash on index
creation
Details:

Just upgraded to PostGIS 1.5.1 on a windows XP machine (from 1.3.4) with
Postgres 8.3 and when creating an index on a geography column using this
single statement;

CREATE INDEX t_swath_metadata_swath_bounding_key ON wastac.t_swath_metadata
USING gist (swath_bounding);

I get a client error

DEBUG: StartTransactionCommandDEBUG: StartTransactionDEBUG: name:
unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0,
nestlvl: 1, children:DEBUG: ProcessUtilityDEBUG: mapped win32 error code 2
to 2
********** Error **********

and find the entire server / postmaster has crashed and no longer running.
Log below;

2010-04-15 22:35:12 EST LOG: database system was interrupted; last known up
at 2010-04-15 22:32:33 EST
2010-04-15 22:35:12 EST LOG: database system was not properly shut down;
automatic recovery in progress
2010-04-15 22:35:13 EST LOG: redo starts at C/F5D9EAB0
2010-04-15 22:35:13 EST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2010-04-15 22:35:13 EST FATAL: the database system is starting up
2010-04-15 22:35:13 EST LOG: unexpected pageaddr C/EEFDE000 in log file 12,
segment 246, offset 16637952
2010-04-15 22:35:13 EST LOG: redo done at C/F6FDCC90
2010-04-15 22:35:13 EST LOG: last completed transaction was at log time
2010-04-15 22:33:37.687+10
2010-04-15 22:35:14 EST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2010-04-15 22:35:14 EST FATAL: the database system is starting up
2010-04-15 22:35:14 EST LOG: database system is ready to accept
connections
2010-04-15 22:35:15 EST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2010-04-15 22:36:22 EST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2010-04-15 22:36:26 EST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2010-04-15 22:36:27 EST LOG: loaded library
"$libdir/plugins/plugin_debugger.dll"
2010-04-15 22:36:35 EST LOG: server process (PID 14600) was terminated by
exception 0xC0000005
2010-04-15 22:36:35 EST HINT: See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-04-15 22:36:35 EST LOG: terminating any other active server processes
2010-04-15 22:36:35 EST WARNING: terminating connection because of crash of
another server process
2010-04-15 22:36:35 EST 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.
2010-04-15 22:36:35 EST HINT: In a moment you should be able to reconnect
to the database and repeat your command.
2010-04-15 22:36:35 EST WARNING: terminating connection because of crash of
another server process
2010-04-15 22:36:35 EST 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.
2010-04-15 22:36:35 EST HINT: In a moment you should be able to reconnect
to the database and repeat your command.
2010-04-15 22:36:35 EST LOG: all server processes terminated;
reinitializing
2010-04-15 22:36:36 EST FATAL: pre-existing shared memory block is still in
use
2010-04-15 22:36:36 EST HINT: Check if there are any old server processes
still running, and terminate them.

I have been using this Postgresql instance (8.3) with PostGIS 1.3.4 for a
long time previously to do similar operations on geometries and never
encountered a crash like this.

I must admit there is not much to go on with that log above - raising to
debug shows below:

2010-04-15 22:48:57 EST DEBUG: StartTransactionCommand
2010-04-15 22:48:57 EST DEBUG: StartTransaction
2010-04-15 22:48:57 EST DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-04-15 22:48:57 EST DEBUG: ProcessUtility
2010-04-15 22:48:57 EST DEBUG: mapped win32 error code 2 to 2
2010-04-15 22:48:59 EST DEBUG: reaping dead processes
2010-04-15 22:48:59 EST DEBUG: server process (PID 15736) was terminated by
exception 0xC0000005
2010-04-15 22:48:59 EST HINT: See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-04-15 22:48:59 EST LOG: server process (PID 15736) was terminated by
exception 0xC0000005
2010-04-15 22:48:59 EST HINT: See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-04-15 22:48:59 EST LOG: terminating any other active server processes
2010-04-15 22:48:59 EST DEBUG: sending SIGQUIT to process 13536
2010-04-15 22:48:59 EST DEBUG: sending SIGQUIT to process 14200
2010-04-15 22:48:59 EST DEBUG: sending SIGQUIT to process 13948
2010-04-15 22:48:59 EST DEBUG: reaping dead processes
2010-04-15 22:48:59 EST DEBUG: reaping dead processes
2010-04-15 22:48:59 EST DEBUG: reaping dead processes
2010-04-15 22:48:59 EST LOG: all server processes terminated;
reinitializing
2010-04-15 22:48:59 EST DEBUG: shmem_exit(0)
2010-04-15 22:48:59 EST DEBUG: invoking IpcMemoryCreate(size=36741120)
2010-04-15 22:49:00 EST FATAL: pre-existing shared memory block is still in
use
2010-04-15 22:49:00 EST HINT: Check if there are any old server processes
still running, and terminate them.
2010-04-15 22:49:00 EST DEBUG: proc_exit(1)
2010-04-15 22:49:00 EST DEBUG: shmem_exit(1)
2010-04-15 22:49:00 EST DEBUG: exit(1)
2010-04-15 22:49:00 EST DEBUG: logger shutting down
2010-04-15 22:49:00 EST DEBUG: proc_exit(0)
2010-04-15 22:49:00 EST DEBUG: shmem_exit(0)
2010-04-15 22:49:00 EST DEBUG: exit(0)

UPDATE TO ORIGINAL EMAIL: After some thorough testing over the last days on
this (I have a datafile that I can provide for pg_restore with which to
reproduce the crash with single index creation statement), it only happens
on Postgres 8.3, and not with Postgres 8.4.

This lessens the impact for us, providing a way around it by upgrading to
8.4, but I would have considered this bug as pretty much the most serious
kind as it brings down the postmaster entirely forcing complete restart.

It also seems completely related to new geography types - we've been using
geometries for a good while.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-04-23 14:01:31 Re: BUG #5436: PostGIS 1.5.1 causing postmaster 8.3 crash on index creation
Previous Message Tom Lane 2010-04-22 14:54:31 Re: BUG #5434: select from xpath_table gives wrong results