Tom Lane wrote:
> "Chris Jones" <chris(at)cjones(dot)org> writes:
>> I used to be decent with gdb, so let me know if there's anything I can do as
>> far as backtraces, etc.
> Try setting a breakpoint at errfinish() and backtracing from there.
Breakpoint 1, 0x081cd8ba in errfinish ()
#0 0x081cd8ba in errfinish ()
#1 0x081ce756 in elog_finish ()
#2 0x081dd6e5 in MemoryContextAlloc ()
#3 0x081ca14c in load_relcache_init_file ()
#4 0x081c9164 in RelationCacheInitialize ()
#5 0x081d4dfe in InitPostgres ()
#6 0x0816facb in PostgresMain ()
#7 0x0811e04d in main ()
#8 0x08072e22 in ___start ()
Because it was built without debugging symbols, I think this is all I
can get for you.
I've dropped this database and restored it from backups to get it
running again. But I've also kept a copy of the erroneous data for
bug-hunting purposes. If you'd like to track this down and/or find a way
to automatically clean up data corrupted in this fashion, I'll be happy
to work with you. If you have no interest, please let me know so I can
delete the files.
In response to
pgsql-bugs by date
|Next:||From: Greg Peters||Date: 2006-11-26 11:38:56|
|Subject: BUG #2781: database dump/restore problems|
|Previous:||From: Thomas H.||Date: 2006-11-26 04:05:37|
|Subject: BUG #2780: could not fsync segment 0|