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/
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 |
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 |