always denying corruption

Marc Munro wrote:

>For the record, here are the results of our (ongoing) inevstigation into
>the index/heap corruption problems I reported a couple of weeks ago.
>
>We were able to trigger the problem with kernels 2.6.16, 2.6.17 and
>2.6.18.rc1, with 2.6.16 seeming to be the most flaky.
>
>By replacing the NFS-mounted netapp with a fibre-channel SAN, we have
>eliminated the problem on all kernels.
>
>From this, it would seem to be an NFS bug introduced post 2.6.14, though
>we cannot rule out a postgres bug exposed by unusual timing issues.
>
>Our starting systems are:
>
>Sun v40z 4 x Dual Core AMD Opteron(tm) Processor 875
>Kernel 2.6.16.14 #8 SMP x86_64 x86_64 x86_64 GNU/Linux (and others)
>kernel boot option: elevator=deadline
>16 Gigs of RAM
>postgresql-8.0.8-1PGDG
>Bonded e1000/tg3 NICs with 8192 MTU.
>Slony 1.1.5
>
>NetApp FAS270 OnTap 7.0.3
>Mounted with the NFS options
>rw,nfsvers=3,hard,rsize=32768,wsize=32768,timeo=600,tcp,noac
>Jumbo frames 8192 MTU.
>
>All postgres data and logs are stored on the netapp.
>
>All tests results were reproduced with postgres 8.0.8
>
>__
>Marc
>
>On Fri, 2006-06-30 at 23:20 -0400, Tom Lane wrote:
>
>
>>Marc Munro <marc(at)bloodnok(dot)com> writes:
>>
>>
>>>We tried all of these suggestions and still get the problem. Nothing
>>>interesting in the log file so I guess the Asserts did not fire.
>>>
>>>
>>Not surprising, it was a long shot that any of those things were really
>>broken. But worth testing.
>>
>>
>>
>>>We are going to try experimenting with different kernels now. Unless
>>>anyone has any other suggestions.
>>>
>>>
>>Right at the moment I have no better ideas :-(
>>
>> regards, tom lane
>>
>>
>
>
>
On a good stock day, some levity is justified. How are hackers like
politicians?

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.1/390 - Release Date: 7/17/2006