Re: [GENERAL] pg_upgrade problem
hubert depesz lubaczewski <depesz@depesz.com>
From: hubert depesz lubaczewski <depesz@depesz.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-09-06T10:32:22Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
ltree support for multibyte encodings. Patch was made by
- 8eee65c99604 8.4.0 cited
On Mon, Sep 05, 2011 at 05:26:00PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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/