Hi,
first of all I would like to thank you for all your efforts.
> We really need a test case.
unfortunately this kind of bugs tend to be non-reproducable. I assume that there is a race condition which is only hit
in rare cases, under heavy load and when mars and venus are exactly aligned... ;-)
I do not think it is possible to construct a test case that reliably reproduces
the bug.
However, we would be glad to incorporate any patches, additional logging code etc. in our installation of postgres that
might help you to track the bug. Since we always build postgres on the production machine this would not be any problem.
Unfortunately we handle very sensitive data in our databases, so we cannot give you direct access to our machines. As a
last resort I would propose the following (provided that our customer agrees):
We set up another machine and feed it with obfuscated data, putting it under the same load as our production machine. We
could then give you root access to that machine and you could do whatever patching, monitoring, testing etc. might be
helpful to track the problem. Do you think this might help?
BTW... how about a block checksum that is checked just before writing a block and just after reading it? I know this
would degrade performance, but I think we can afford that. Would it be possible to incorporate such code without having
to do too much patching?
Thanks in advance
Alexandra Nitzschke
Thomas Goerner
Tom Lane schrieb:
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
Yes, its a btree.
Well, the btree code is sufficiently well tested/debugged that I think
there's zero chance of finding such a bug in it just on the suspicion
that there might be one there. We really need a test case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
