Teodor:
Thanks for the followup. We will be upgrading this system to
8.2.5 in the next day or so and will test it on that anyways just to
be sure it isn't related. Let me know if there is anything else we
can provide to help track down the bug. We will be keeping this base
backup and WAL files around so that we can use them for testing.
Cheers,
-craig
---
Craig A. McElroy
Contegix
Beyond Managed Hosting(r) for Your Enterprise
On Oct 25, 2007, at 1:05 PM, Teodor Sigaev wrote:
#0 0x080b8ee0 in entrySplitPage ()
#1 0x080baccf in ginInsertValue ()
Corrupted stack? gin_xlog_cleanup() doesn't call ginInsertValue()
directly.
#2 0x080b81b7 in gin_xlog_cleanup ()
#3 0x080af4ce in StartupXLOG ()
#4 0x080c04ca in BootstrapMain ()
#5 0x08186b2f in StartChildProcess ()
#6 0x081889eb in PostmasterMain ()
#7 0x0814ee9e in main ()
Teodor, can you comment on whether this stack trace looks like it
could
be related to that fix?
No, I suppose. That changes was about deadlock prevention,
recognize splits and
fixes in deletion of page in a posting tree. entrySplitPage() is a
split of page of indexed values.
Hmm. I suppose, I found a reason. Real backtrace should look like:
gin_xlog_cleanup()
ginContinueSplit()
prepareEntryScan(,,,NULL) // makes btree.ginstate = NULL
ginInsertValue()
entrySplitPage() // tries to access
// btree->ginstate->tupdesc in
// 497 line
That piece of code:
value = index_getattr(leftrightmost, FirstOffsetNumber, btree-
>ginstate->tupdesc, &isnull);
btree->entry = GinFormTuple(btree->ginstate, value, NULL, 0);
ItemPointerSet(&(btree->entry)->t_tid, BufferGetBlockNumber
(lbuf), InvalidOffsetNumber);
It just makes new tuple with the same value and another
ItemPointer. Some later I'll make a patch which will not call
index_getattr() and GinFormTuple() - now I know how make a test suite.
--
Teodor Sigaev E-mail:
[EMAIL PROTECTED]
WWW: http://
www.sigaev.ru/
---------------------------(end of
broadcast)---------------------------
TIP 6: explain analyze is your friend