I agree about keeping it simple for the users. Anyway if that
shows up a bad problems with either the implementation or the
operating system of the users it would be nice to know how
to inspect it further. In my case this could also help
debugging a postgres extension (postgis) which is involved in
text->internal conversion and is showing heap corruption problems.
The question now is: what does that message mean ? Did a routine
try to create an index and left its work before finishing it ?
--strk;
JanWieck wrote:
> Christopher Kings-Lynne wrote:
>
> >> I couldn't agree more. Look at this very instance. He now found the
> >> right reindex command and the corrupted file is gone. We don't have the
> >> slightest clue what happened to that file. Was it truncated? Did some
> >> other process scribble around in the shared memory? How do you tell now?
> >
> > The end user just could not care less. They want their machine running
> > again as soon as is humanly possible without going through a back and
> > forth process of subscribing to some lists they don't care about, etc.
>
> I know, that's (unfortunately) true. Although it's not very farsighted
> because better bug reports usually lead to better software in the next
> release.
>
>
> Jan
>
> --
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #================================================== JanWieck@Yahoo.com #