Skip site navigation (1) Skip section navigation (2)

problems recovering 6.1 db

From: Andrey V Khavryutchenko <akhavr(at)compchem(dot)kiev(dot)ua>
To: pgsql-hackers(at)postgresql(dot)org
Subject: problems recovering 6.1 db
Date: 1998-12-30 11:05:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

I have to recover old db, produced by pgsql 6.1.  The binaries are lost and 
fresh compiled postgres dumps core.  Investigation narrowed the problem
down to postgresql-v6.1.1/src/backend/utils/cache/catcache.c:comphash

With debug turned on, I'm getting the following output:

[akhavr(at)kbi akhavr]$ date; sudo -u postgres /home/akhavr/postgres \
-D /home/postgres/data -e -d 2 mailingad
Wed Dec 30 12:40:32 EET 1998
FindBackend: found "/home/akhavr/postgres" using argv[0]
	---debug info---
	Quiet =        f
	Noversion =    f
	stable    =    f
	timings   =    f
	dates     =    European
	bufsize   =    64
	query echo =   f
	multiplexed backend? =  f
	DatabaseName = [mailingad]

binding ShmemCreate(key=0, size=758552)
DEBUG:InitSysCache: rid=0 id=0 nkeys=3 size=500
DEBUG:CatalogCacheInitializeCache: cache @081d3720
DEBUG:CatalogCacheInitializeCache: called w/relname pg_user
DEBUG:CatalogCacheInitializeCache: relid 1260, 1 keys
DEBUG:CatalogCacheInitializeCache: load 1/1 w/1, -1
DEBUG:CatalogCacheInit          pg_user 0 -1 81d3720
DEBUG:CatalogCacheComputeHashIndex pg_user 1 -1 0 81d3720
DEBUG:comphash (-1,8187980)
Segmentation fault (core dumped)
[akhavr(at)kbi akhavr]$ sudo cp /home/postgres/data/base/mailingad/core .; \
sudo chown akhavr core
[akhavr(at)kbi akhavr]$ gdb postgres core
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i586-ksi-linux), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `/home/akhavr/postgres -D /home/postgres/data -e -d 2 mailingad'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/
Reading symbols from /lib/
Reading symbols from /lib/
Reading symbols from /usr/lib/
Reading symbols from /lib/
Reading symbols from /lib/
Reading symbols from /lib/
#0  comphash (l=1953333615, v=0x8187200 "postgres") at catcache.c:299
299             i += *v++;
(gdb) bt
#0  comphash (l=1953333615, v=0x8187200 "postgres") at catcache.c:299
#1  0x8136cec in CatalogCacheComputeHashIndex (cacheInP=0x81d2fa0)
    at catcache.c:334
#2  0x813751b in SearchSysCache (cache=0x81d2fa0, v1=135819776, v2=0, v3=0,
    v4=0) at catcache.c:773
#3  0x813a65e in SearchSysCacheTuple (cacheId=21, key1=135819776, key2=0,
    key3=0, key4=0) at syscache.c:416
#4  0x813ef2b in SetUserId () at miscinit.c:331
#5  0x813f40b in InitUserid () at postinit.c:341
#6  0x813f661 in InitPostgres (name=0xbffffce1 "mailingad") at postinit.c:636
#7  0x8107aaf in PostgresMain (argc=7, argv=0xbffffb94) at postgres.c:1237
#8  0x80b144d in main (argc=7, argv=0xbffffb94) at main.c:68
#9  0x806238e in _start ()

Looks like l is treated as unsigned.

Can anyone suggest the way to fix the bug, so I can dump out the db and
reload it to the last stable postgresql version?

SY, Andrey V Khavryutchenko

Shick's Law:
	There is no problem a good miracle can't solve.


pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-12-30 14:55:44
Subject: Re: [HACKERS] NUMERIC needs OID's
Previous:From: Thomas G. LockhartDate: 1998-12-30 06:23:45
Subject: Re: [HACKERS] NUMERIC needs OID's

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group