Re: [GENERAL] pg_upgrade problem

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] pg_upgrade problem
Date: 2011-09-06 10:32:22
Message-ID: 20110906103222.GA20760@depesz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, Sep 05, 2011 at 05:26:00PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Odd it is dying in the memory freeing at executor close --- not in the
> > ltree code.
>
> Doesn't seem odd. The glibc complaint previously shown already
> indicates this is a memory stomp problem.
>
> --enable-cassert might (or might not) provide additional help.

recompiled with cassert.

result:

=# select * from categories where category_id = 177;
The connection to the server was lost. Attempting reset: Succeeded.

which is interesting, as the error is different.

logs show:

2011-09-06 10:28:58 UTC () [21986]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=[local]
2011-09-06 10:28:58 UTC ([local]) [21986]: [2-1] user=postgres,db=xxxxxxx LOG: connection authorized: user=postgres database=xxxxxxx
2011-09-06 10:28:58 UTC () [21977]: [2-1] user=,db= LOG: server process (PID 21985) was terminated by signal 11: Segmentation fault
2011-09-06 10:28:58 UTC () [21977]: [3-1] user=,db= LOG: terminating any other active server processes
2011-09-06 10:28:58 UTC ([local]) [21986]: [3-1] user=postgres,db=xxxxxxx WARNING: terminating connection because of crash of another server process
2011-09-06 10:28:58 UTC ([local]) [21986]: [4-1] user=postgres,db=xxxxxxx 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.
2011-09-06 10:28:58 UTC ([local]) [21986]: [5-1] user=postgres,db=xxxxxxx HINT: In a moment you should be able to reconnect to the database and repeat your command.

gdb backtrace is even less helpful:

$ gdb -q -c core* /opt/pgsql-9.0.5a-int/bin/postgres

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `postgres: postgres xxxxxxx [local] SELECT '.
Program terminated with signal 11, Segmentation fault.
[New process 21985]
#0 0x00007fe18c235e4b in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00007fe18c235e4b in memcpy () from /lib/libc.so.6
#1 0x00007fe1897532e4 in ?? ()
#2 0x0000000000000000 in ?? ()
(gdb)

Best regards,

depesz

--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message hubert depesz lubaczewski 2011-09-06 11:13:58 Re: [GENERAL] pg_upgrade problem
Previous Message MirrorX 2011-09-06 09:41:33 Re: warm standby - apply wal archives

Browse pgsql-hackers by date

  From Date Subject
Next Message hubert depesz lubaczewski 2011-09-06 11:13:58 Re: [GENERAL] pg_upgrade problem
Previous Message Heikki Linnakangas 2011-09-06 10:21:28 Re: B-tree parent pointer and checkpoints