Обсуждение: problems recovering 6.1 db

Hi!

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@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 =        fNoversion =    fstable    =
ftimings  =    fdates     =    Europeanbufsize   =    64query echo =   fmultiplexed backend? =  fDatabaseName =
[mailingad]----------------
InitPostgres()..
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@kbi akhavr]$ sudo cp /home/postgres/data/base/mailingad/core .; \
sudo chown akhavr core
[akhavr@kbi akhavr]$ gdb postgres core
GDB is free software and you are welcome to distribute copies of itunder certain conditions; type "show copying" to see
theconditions.
 
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/libcrypt.so.1...done.
Reading symbols from /lib/libdl.so.1...done.
Reading symbols from /lib/libm.so.5...done.
Reading symbols from /usr/lib/libreadline.so.2...done.
Reading symbols from /lib/libtermcap.so.2...done.
Reading symbols from /lib/libc.so.5...done.
Reading symbols from /lib/ld-linux.so.1...done.
#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 ()
(gdb)

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    http://www.kbi.kiev.ua/~akhavr

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

> I have to recover old db, produced by pgsql 6.1.  The binaries are 
> lost and fresh compiled postgres dumps core.
> 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?

Out of curiosity, what platform are you running on? I've still got v6.1
(and v6.1.1) tar files and source trees on my linux/libc5 machine, and
could build binaries for you if they happen to match. Are you *sure* you
had a v6.1 installation, as opposed to a v6.1.1? Both releases had fixes
for some hashing operations, and I'll bet they need to match exactly
with your database.

Also, if your "mailingad" database is small, not confidential, and
binary compatible with my machine I could try reading it here.

Good luck.
                      - Tom

Hi, Thomas! 

>>>>> "TGL" == Thomas G Lockhart writes:

>> I have to recover old db, produced by pgsql 6.1.  The binaries are lost
>> and fresh compiled postgres dumps core.  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?

TGL> Out of curiosity, what platform are you running on? I've still got
TGL> v6.1 (and v6.1.1) tar files and source trees on my linux/libc5
TGL> machine, and could build binaries for you if they happen to match. Are
TGL> you *sure* you had a v6.1 installation, as opposed to a v6.1.1? 

I'm running linux/libc5.  And, yes, I'm not sure, that which version was
used to create db.  I've tried to use 6.1.1, now I'll try to build 6.1 and
retry.

TGL> Both releases had fixes for some hashing operations, and I'll bet they
TGL> need to match exactly with your database.

TGL> Also, if your "mailingad" database is small, not confidential, and
TGL> binary compatible with my machine I could try reading it here.

Unfortunately, it's impossible.  It's several hunderds megabytes and
limited access. 

Thanks!  If I'll fail with 6.1 too, I'll repost.

-- 
SY, Andrey V Khavryutchenko    http://www.kbi.kiev.ua/~akhavr

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