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 по дате отправления: