Re: "create implicit sequence" crashes postgres

On Monday 04 February 2008 19:31:12 Tom Lane wrote:
> News to me too.  Can you get a stack trace from the crash?  Can you
> extract a small test case from your dump script, so people can try it
> elsewhere?

Damn, figured I was the only one :(

I've never actually used gdb before, so this is probably completely wrong.
After recompiling postgresql to get this:

# ls -lh /usr/bin/postgres /usr/bin/psql
-rwxr-xr-x 1 root root 63M Feb 4 22:01 /usr/bin/postgres
-rwxr-xr-x 1 root root 2.7M Feb 4 22:02 /usr/bin/psql

In one shell I ran the following as postgres:

$ postgres -D /var/lib/postgresql/data/

In another I then did this:

$ gdb /usr/bin/psql
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/psql
Welcome to psql 8.2.6, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

postgres=# CREATE TABLE billing_transaction_items (
id serial NOT NULL,
billing_transaction_id integer NOT NULL,
pricing_term_id integer,
product_id integer NOT NULL,
is_free boolean NOT NULL,
is_visible boolean NOT NULL,
created_at timestamp without time zone NOT NULL,
updated_at timestamp without time zone NOT NULL,
cost numeric(15,4) DEFAULT 0.0 NOT NULL,
tax numeric(15,4) DEFAULT 0.0 NOT NULL,
quoted_cost numeric(15,4) DEFAULT 0.0 NOT NULL,
quoted_tax numeric(15,4) DEFAULT 0.0 NOT NULL
);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Program received signal SIGINT, Interrupt.
0x00002ac94da51950 in ?? ()
(gdb) bt
#0 0x00002ac94da51950 in ?? ()
#1 0x00002ac94d4f2810 in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb) Quit

There is no other output, and no core dump is ever left, even after "ulimit -c
unlimited", as shown in the log the master process doesn't crash instead it
starts an immediate recovery.
If there is a way to get a proper stack trace I can do that, the server isn't
in use yet due to this problem.

I have however found a "fix". We use hardened Gentoo everywhere, on all the
64bit Xen VMs and 64bit proper server (that does not crash!), but not the 8.1
VM as that is a 32bit Centos install thrown together as a dev environment.
Compiling postgresql non-hardened allows me to create any table I like, and
throw a couple hundred meg of data and schema at it in one go.

The 64bit server does all the compiling for all the VMs (including the
non-hardened postgresql build), but differs from the VMs in one probably
inconsequencial way, it runs a GRSec enabled kernel but the VMs dont (due to
the Xen and GRSec patches conflicting at the time of build).

--
Mike Williams
System Administration Manager - Comodo
Office Tel Europe: +44 (0) 161 8747070
Fax Europe: +44 (0) 161 8771767