Thread: BUG #5736: 9.0.1 segmentation fault (sig11) during long-lived update

The following bug has been logged online:

Bug reference:      5736
Logged by:          Henry
Email address:      henka@cityweb.co.za
PostgreSQL version: 9.0.1
Operating system:   Linux
Description:        9.0.1 segmentation fault (sig11) during long-lived
update
Details:

Hi,

I'm using PostgreSQL 9.0.1 on centos 5.4.

I'm running the following update (which takes a few days to run before I get
the error - twice now):

update tab1 set col1 = hashtext(col0) where col1 isnull;

I'm running this update as part of an exercise to purge duplicates, before
creating a UNIQUE index.

Error from PG:

server process (PID 19328) was terminated by signal 11: Segmentation fault
terminating any other active server processes
...

Before I run this again, what's the best way to proceed to get a core dump
so I can run a gdb backtrace to provide more info?  Simply 'ulimit -c
5242880' as user postgres and restart PG?

Thanks

"Henry" <henka@cityweb.co.za> writes:
> Before I run this again, what's the best way to proceed to get a core dump
> so I can run a gdb backtrace to provide more info?  Simply 'ulimit -c
> 5242880' as user postgres and restart PG?

I'd use "ulimit -c unlimited", myself, rather than making arbitrary
assumptions about how big the corefile might be.

Also, make sure the ulimit command is effective in the shell that will
actually launch the postmaster.  This can be tricky if your PG launch
script uses "su".  If you're using the RH or PGDG RPMs' initscript,
I'd suggest putting the ulimit command in ~postgres/.bash_profile.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Also, make sure the ulimit command is effective in the shell that will
> actually launch the postmaster.  This can be tricky if your PG launch
> script uses "su".  If you're using the RH or PGDG RPMs' initscript,
> I'd suggest putting the ulimit command in ~postgres/.bash_profile.

Under debian or ubuntu you can add the -c switch to pg_ctl options so
that IIRC it will change the ulimit settings for you. An example on a
8.4 install:

$ cat /etc/postgresql/8.4/main/pg_ctl.conf
# Automatic pg_ctl configuration
# This configuration file contains cluster specific options to be passed to
# pg_ctl(1).

pg_ctl_options = ''

Also see the /etc/postgresql/X.Y/cluster/environment file. For archives
sake and people following without a debian based installation handy:

$ cat /etc/postgresql/8.4/main/environment
# environment variables for postmaster process
# This file has the same syntax as postgresql.conf:
#  VARIABLE = simple_value
#  VARIABLE2 = 'any value!'
# I. e. you need to enclose any value which does not only consist of letters,
# numbers, and '-', '_', '.' in single quotes. Shell commands are not
# evaluated.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

I think we can close this bug report.  It would seem that at roughly the same
time as the problem, the RAID store had a hiccup.

The update is still running without error, so it looks like the RAID problem
was probably the cause.  If the situation changes, I'll rebport back.

Apologies for the possibly incorrect report.

Regards
Henry