Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes |
| Дата | |
| Msg-id | 28493.933521257@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes ("Oliver Elphick" <olly@lfix.co.uk>) |
| Ответы |
Re: [HACKERS] Re: Bug#41277: postgresql 6.5.1-3 + sparc (sun4u) == nasty nasty crashes
|
| Список | 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 по дате отправления: