Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes - Mailing list pgsql-ports

From Tom Lane
Subject Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes
Date
Msg-id 28493.933521257@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes  ("Oliver Elphick" <olly@lfix.co.uk>)
Responses Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes  (Adam Di Carlo <adam@onshore.com>)
List pgsql-ports
"Oliver Elphick" <olly@lfix.co.uk> writes:
>> Yes.  On followup, I am getting intermittant hard crashes when running
>> regress.sh or doing any operation with postgresql.  Obviously, this is
>> more on the level of a sparc64 kernel problem, even, than a purely
>> postgres problem -- after all, no user process should be able to take
>> out the system this way.

Yipes...

> Can postgresql developers tell from this what routine we are in when the
> crash occurs?  I suppose that log output is buffered; where can we turn
> off buffering so that all possible output is saved to disk before the
> crash?

The log is not nearly detailed enough to tell what routine we're in,
even if there weren't the buffering problem.  Also, given that this is
a kernel crash, I'm not sure I'd assume that even fsync() after every
line of output would ensure that the last line made it to disk.

What you really want is a truss or strace log of kernel calls, anyhow,
but there's still the problem of getting it out to disk before the
crash.  Better find a kernel-debugging expert to ask for advice...

            regards, tom lane

pgsql-ports by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PORTS] NT-Compile-Hints
Next
From: Adam Di Carlo
Date:
Subject: Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes