Обсуждение: restoreing dumps fail
I'm trying to upgrade from 7.1.3 to 7.2.1 and after makeing a dump, installing
the new version (7.2.1) making the initdb as postgres, when I try to dump all
the data back to the database, and after some dump the backend dies:
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
What's wrong? I can't finish the upgrade if I can't get my data back!
Any help will be apretiated.
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> I'm trying to upgrade from 7.1.3 to 7.2.1 and after makeing a dump, installing
> the new version (7.2.1) making the initdb as postgres, when I try to dump all
> the data back to the database, and after some dump the backend dies:
> NOTICE: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend
> died abnormally and possibly corrupted shared memory.
Oh? What's in the postmaster log? Can you get a stack trace from
the core file that the crashed backend left?
regards, tom lane
On Lun 13 May 2002 23:34, Tom Lane wrote:
> =?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> > I'm trying to upgrade from 7.1.3 to 7.2.1 and after makeing a dump,
> > installing the new version (7.2.1) making the initdb as postgres, when I
> > try to dump all the data back to the database, and after some dump the
> > backend dies:
> >
> > NOTICE: Message from PostgreSQL backend:
> > The Postmaster has informed me that some other backend
> > died abnormally and possibly corrupted shared memory.
I went back to 7.1.3 because the server was in production, and couldn't wait
for me to solve the problem. I'll try to upgrade next week.
> Oh? What's in the postmaster log? Can you get a stack trace from
> the core file that the crashed backend left?
What I would like to know is what to do when I have these problems? Get the
core file and run a strace over it? Run gdb over the core?
Thanks.
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
On Lun 13 May 2002 23:34, Tom Lane wrote:
> =?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> > I'm trying to upgrade from 7.1.3 to 7.2.1 and after makeing a dump,
> > installing the new version (7.2.1) making the initdb as postgres, when I
> > try to dump all the data back to the database, and after some dump the
> > backend dies:
> >
> > NOTICE: Message from PostgreSQL backend:
> > The Postmaster has informed me that some other backend
> > died abnormally and possibly corrupted shared memory.
>
> Oh? What's in the postmaster log? Can you get a stack trace from
> the core file that the crashed backend left?
OK. I installed a seperated postgres server and put it to listen in port
15432. I tried to do a restore and got the same error.
This what the errors say:
2002-05-14 10:23:36 DEBUG: connection: host=[local] user=martin
database=webunl
/dbs/postgres.new/bin/postmaster child[15138]: starting with (postgres -d2
-v131072 -p webunl )
2002-05-14 10:23:36 DEBUG: InitPostgres
2002-05-14 10:23:36 DEBUG: StartTransactionCommand
2002-05-14 10:23:36 DEBUG: query: select getdatabaseencoding()
2002-05-14 10:23:36 DEBUG: ProcessQuery
2002-05-14 10:23:36 DEBUG: CommitTransactionCommand
2002-05-14 10:23:36 DEBUG: StartTransactionCommand
2002-05-14 10:23:36 DEBUG: query: SELECT usesuper FROM pg_user WHERE usename
= 'martin'
2002-05-14 10:23:36 DEBUG: ProcessQuery
2002-05-14 10:23:36 DEBUG: CommitTransactionCommand
2002-05-14 10:23:36 DEBUG: StartTransactionCommand
2002-05-14 10:23:36 DEBUG: query: CREATE SEQUENCE "facultad_id_fac_seq" start
1 increment 1 maxvalue 2147483647 minvalue 1 cache 1 ;
2002-05-14 10:23:36 DEBUG: ProcessUtility: CREATE SEQUENCE
"facultad_id_fac_seq" start 1 increment 1 maxvalue 2147483647 minvalue 1
cache 1 ;
2002-05-14 10:23:36 DEBUG: INSERT @ 0/22CC90: prev 0/22CC68; xprev 0/0; xid
427; bkpb 1: Heap - insert: node 16893/1259; tid 1/11
2002-05-14 10:23:36 DEBUG: INSERT @ 0/22ECF0: prev 0/22CC90; xprev 0/22CC90;
xid 427; bkpb 1: Btree - insert: node 16893/16429; tid 1/1
2002-05-14 10:23:36 DEBUG: INSERT @ 0/230D50: prev 0/22ECF0; xprev 0/22ECF0;
xid 427; bkpb 1: Btree - insert: node 16893/16428; tid 1/102
2002-05-14 10:23:36 DEBUG: proc_exit(0)
2002-05-14 10:23:36 DEBUG: shmem_exit(0)
2002-05-14 10:23:36 DEBUG: exit(0)
2002-05-14 10:23:36 DEBUG: reaping dead processes
2002-05-14 10:23:36 DEBUG: child process (pid 15137) was terminated by signal
10
2002-05-14 10:23:36 DEBUG: server process (pid 15137) was terminated by
signal 10
2002-05-14 10:23:36 DEBUG: terminating any other active server processes
2002-05-14 10:23:36 DEBUG: CleanupProc: sending SIGQUIT to process 15138
2002-05-14 10:23:36 NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
2002-05-14 10:23:36 DEBUG: reaping dead processes
2002-05-14 10:23:36 DEBUG: child process (pid 15138) exited with exit code 1
2002-05-14 10:23:36 DEBUG: all server processes terminated; reinitializing
shared memory and semaphores
2002-05-14 10:23:36 DEBUG: shmem_exit(0)
invoking IpcMemoryCreate(size=3563520)
2002-05-14 10:23:36 DEBUG: database system was interrupted at 2002-05-14
10:22:27 GMT
2002-05-14 10:23:36 DEBUG: checkpoint record is at 0/113640
2002-05-14 10:23:36 DEBUG: redo record is at 0/113640; undo record is at 0/0;
shutdown TRUE
2002-05-14 10:23:36 DEBUG: next transaction id: 89; next oid: 16556
2002-05-14 10:23:36 DEBUG: database system was not properly shut down;
automatic recovery in progress
About the trace of the core, first I don't know exactly what to do, and
second, I can't find a core file (or does it have another name?)
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> 2002-05-14 10:23:36 DEBUG: child process (pid 15137) was terminated by signal
> 10
Hmm, apparently a bus error?
> About the trace of the core, first I don't know exactly what to do, and
> second, I can't find a core file (or does it have another name?)
It should be named core (or some variant; some platforms include the PID
or the program name, but pretty much everybody includes "core" in the
name). And it will definitely be located in $PGDATA/base/yourdbnumber/.
If you don't see one there then you probably started the postmaster with
ulimit -c 0. Change to ulimit -c unlimited and try again.
Once you get a core do
gdb $INSTALL/bin/postgres $PGDATA/base/yourdbnumber/core
gdb> bt
gdb> quit
If the bt produces only a list of numbers and no symbolic info then
it will be little help. In that case, please recompile Postgres with
debug support (configure --enable-debug) and try again.
regards, tom lane
On Mar 14 May 2002 10:58, Tom Lane wrote:
> =?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> > 2002-05-14 10:23:36 DEBUG: child process (pid 15137) was terminated by
> > signal 10
>
> Hmm, apparently a bus error?
>
> > About the trace of the core, first I don't know exactly what to do, and
> > second, I can't find a core file (or does it have another name?)
>
> It should be named core (or some variant; some platforms include the PID
> or the program name, but pretty much everybody includes "core" in the
> name). And it will definitely be located in $PGDATA/base/yourdbnumber/.
>
> If you don't see one there then you probably started the postmaster with
> ulimit -c 0. Change to ulimit -c unlimited and try again.
>
> Once you get a core do
> gdb $INSTALL/bin/postgres $PGDATA/base/yourdbnumber/core
> gdb> bt
(gdb) bt
#0 0xff030b64 in __do_global_dtors_aux () from
/dbs/postgres/lib/array_iterator.so
#1 0xff030af8 in _fini () from /dbs/postgres/lib/array_iterator.so
#2 0xff3b9f5c in ?? ()
#3 0xff0a00d0 in _exithandle () from /usr/lib/libc.so.1
#4 0xff116814 in exit () from /usr/lib/libc.so.1
#5 0x1bea40 in proc_exit (code=0) at ipc.c:155
#6 0x1d69c8 in PostgresMain (argc=5, argv=0xffbef1e8, username=0x46d319
"postgres") at postgres.c:1951
#7 0x197df0 in DoBackend (port=0x46d1e8) at postmaster.c:2243
#8 0x197288 in BackendStartup (port=0x46d1e8) at postmaster.c:1874
#9 0x1957dc in ServerLoop () at postmaster.c:977
#10 0x195058 in PostmasterMain (argc=3, argv=0x455fb8) at postmaster.c:771
#11 0x1501fc in main (argc=3, argv=0xffbefc9c) at main.c:206
(gdb)
Could it be a problem with array_iterator.so???
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> (gdb) bt
> #0 0xff030b64 in __do_global_dtors_aux () from
> /dbs/postgres/lib/array_iterator.so
> #1 0xff030af8 in _fini () from /dbs/postgres/lib/array_iterator.so
> #2 0xff3b9f5c in ?? ()
> #3 0xff0a00d0 in _exithandle () from /usr/lib/libc.so.1
> #4 0xff116814 in exit () from /usr/lib/libc.so.1
> #5 0x1bea40 in proc_exit (code=0) at ipc.c:155
> #6 0x1d69c8 in PostgresMain (argc=5, argv=0xffbef1e8, username=0x46d319
> "postgres") at postgres.c:1951
Hmm, that's bizarre. How did you compile the array_iterator module?
There is no _fini routine in the source code, so this must be something
inserted by the compiler.
regards, tom lane
On Mar 14 May 2002 12:17, Tom Lane wrote:
> =?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> > (gdb) bt
> > #0 0xff030b64 in __do_global_dtors_aux () from
> > /dbs/postgres/lib/array_iterator.so
> > #1 0xff030af8 in _fini () from /dbs/postgres/lib/array_iterator.so
> > #2 0xff3b9f5c in ?? ()
> > #3 0xff0a00d0 in _exithandle () from /usr/lib/libc.so.1
> > #4 0xff116814 in exit () from /usr/lib/libc.so.1
> > #5 0x1bea40 in proc_exit (code=0) at ipc.c:155
> > #6 0x1d69c8 in PostgresMain (argc=5, argv=0xffbef1e8, username=0x46d319
> > "postgres") at postgres.c:1951
>
> Hmm, that's bizarre. How did you compile the array_iterator module?
> There is no _fini routine in the source code, so this must be something
> inserted by the compiler.
Could it be, that the array_iterator was compiled with some old postgres-7.0.x
and then was left there???
It's the only thing I can think of.
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
>> Hmm, that's bizarre. How did you compile the array_iterator module?
>> There is no _fini routine in the source code, so this must be something
>> inserted by the compiler.
> Could it be, that the array_iterator was compiled with some old postgres-7.0.x
> and then was left there???
That's a good point. Look at your dump script to see if it's trying to
do any CREATE FUNCTION commands with absolute paths to .so files. If
so, you probably want to fix those to be $libdir-relative paths (a new
feature in 7.2, makes maintenance a lot easier).
regards, tom lane
On Mar 14 May 2002 12:27, Tom Lane wrote:
> =?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:
> >> Hmm, that's bizarre. How did you compile the array_iterator module?
> >> There is no _fini routine in the source code, so this must be something
> >> inserted by the compiler.
> >
> > Could it be, that the array_iterator was compiled with some old
> > postgres-7.0.x and then was left there???
>
> That's a good point. Look at your dump script to see if it's trying to
> do any CREATE FUNCTION commands with absolute paths to .so files. If
> so, you probably want to fix those to be $libdir-relative paths (a new
> feature in 7.2, makes maintenance a lot easier).
Done!!! Thaks for all the tups Tom!
Recompiled the array_iterator.so, copied it to the new lib dir, and now it
passed like a charme. :-)
Lots of thanks to all!!!
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------