Re: postgres segfaulting on pg_restore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: chris(at)chriscurvey(dot)com
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-general(at)postgresql(dot)org, martin(dot)pitt(at)ubuntu(dot)com
Subject: Re: postgres segfaulting on pg_restore
Date: 2011-05-03 21:08:37
Message-ID: 25848.1304456917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Chris Curvey <chris(at)chriscurvey(dot)com> writes:
> and, FWIW, here's another trace, which is NEARLY the same as the first one I
> posted, with the difference being a slightly different line number at #3. I
> will be quiet now and leave the brain trust to ponder. Let me know if there
> is anything else I can get for you guys.

> #0 0x00000000006ce317 in GetMemoryChunkSpace (pointer=0x292a0e0) at
> mcxt.c:264
> #1 0x00000000006d3d56 in writetup_index (state=0x2281670, tapenum=<value
> optimized out>, stup=<value optimized out>) at tuplesort.c:2924

It occurred to me that a simple explanation for a core dump there would
be if something had scribbled past the end of the preceding palloc
chunk. That would tend to clobber the "context" link of the palloc
chunk after it, which would send GetMemoryChunkSpace off into
never-never land following a trashed pointer.

That doesn't get us very much closer to a solution, but it does suggest
that you might learn something if you try this with an assert-enabled
build (configure --enable-cassert). Also, are there any contrib modules
or third-party add-on modules or home-brew C functions that you're using?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Davis 2011-05-03 21:11:36 Re: pervasiveness of surrogate (also called synthetic) keys
Previous Message Jeff Davis 2011-05-03 21:08:33 Re: pervasiveness of surrogate (also called synthetic) keys