Craig Ringer <craig@postnewspapers.com.au> writes:
> On 17/12/2010 11:17 PM, Tom Lane wrote:
>> There is absolutely nothing more frustrating than having a crash dump
>> that hasn't got the information you need. Please turn it on by default.
> There have to be limits to that, though. dbghelp.dll can dump shared
> memory, too - but it's not going to be practical to write or work with
> many-gigabyte dumps most of the time, and neither my initial patch nor
> Magnus's recent reworking of it ask windbg.dll to include shared memory
> in the dump.
Well, actually my comment above is based directly on pain in working
with core dumps on Unix-oid systems that don't include shared memory.
Linux *does* include shared memory, and I have not noticed that that
was a problem. Of course, in development installations I don't try to
raise shared_buffers to the moon ...
> It's possible to tell dbghelp.dll to include specific additional memory
> ranges, so it may well be worth including specific critical areas within
> the shared memory block while omitting the bulk of the buffers. Doing
> that safely in an unsafe we're-crashing environment might not be simple,
> though, especially if you're not even sure whether you got far into
> startup before crashing.
I agree that having the crash dump code know anything specific about the
contents of shared memory is a nonstarter --- far too fragile. But
perhaps we could have some simple rule based only on what the kernel
knows about the shmem block, like "dump shmem if it's no more than 1GB".
regards, tom lane