"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> LOG: database system was interrupted; last known up at 2010-08-30
> 09:13:23 CDT
> LOG: database system was not properly shut down; automatic recovery in
> progress
> LOG: consistent recovery state reached at 0/5C5D04
> LOG: redo starts at 0/5C5D04
> TRAP: FailedAssertion("!(backend == (-1))", File: "catalog.c", Line:
> 120)
> LOG: startup process (PID 5338) was terminated by signal 6: Aborted
> LOG: aborting startup due to startup process failure
I can reproduce this; looks like it is fallout from the
RelFileNodeBackend patch. Stack trace from core dump is
#4 0x4f912c in ExceptionalCondition (
conditionName=0x89054 "!(backend == (-1))",
errorType=0x89044 "FailedAssertion", fileName=0x88fc8 "catalog.c",
lineNumber=120) at assert.c:57
#5 0x2473b8 in relpathbackend (rnode={spcNode = 1664, dbNode = 0,
relNode = 11617}, backend=2063810256, forknum=2063672808)
at catalog.c:120
#6 0x40a628 in mdopen (reln=0x40096748, forknum=VISIBILITYMAP_FORKNUM,
behavior=EXTENSION_RETURN_NULL) at md.c:508
#7 0x409ce0 in mdexists (reln=0x40096748, forkNum=VISIBILITYMAP_FORKNUM)
at md.c:237
#8 0x40c7ac in smgrexists (reln=0x7b011c28, forknum=2063848444) at smgr.c:207
#9 0x1f2464 in vm_readbuf (rel=0x40061bc0, blkno=0, extend=0 '\000')
at visibilitymap.c:410
#10 0x1f1b80 in visibilitymap_clear (rel=0x7b011c28, heapBlk=2063848444)
at visibilitymap.c:147
#11 0x1e924c in heap_xlog_insert (lsn={xlogid = 0, xrecoff = 26015704},
record=0x30) at heapam.c:4389
#12 0x1eaec8 in heap_redo (lsn={xlogid = 0, xrecoff = 26015704},
record=0x40083f70) at heapam.c:4823
#13 0x21bbd4 in StartupXLOG () at xlog.c:6229
#14 0x2215f8 in StartupProcessMain () at xlog.c:9233
#15 0x24571c in AuxiliaryProcessMain (argc=2, argv=0x7b03ade8)
at bootstrap.c:412
#16 0x3cb560 in StartChildProcess (type=StartupProcess) at postmaster.c:4407
#17 0x3c6f6c in PostmasterMain (argc=3, argv=0x7b03aba0) at postmaster.c:1089
#18 0x34d998 in main (argc=3, argv=0x7b03aba0) at main.c:188
I guess that something isn't properly setting up rnode.backend in
recovery processing, but didn't find it yet.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
