From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Paolo Bizzarri <pibizza(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Corruption of files in PostgreSQL |
Date: | 2007-06-04 21:01:22 |
Message-ID: | 46647DA2.2080104@g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Paolo Bizzarri wrote:
> On 6/2/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> "Paolo Bizzarri" <pibizza(at)gmail(dot)com> writes:
>> > On 6/2/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >> Please provide a reproducible test case ...
>>
>> > as explained above, the problem seems quite random. So I need to
>> > understand what we have to check.
>>
>> In this context "reproducible" means that the failure happens
>> eventually. I don't care if the test program only fails once in
>> thousands of tries --- I just want a complete self-contained example
>> that produces a failure.
>
> As said above, our application is rather complex and involves several
> different pieces of software, including Zope, OpenOffice both as
> server and client, and PostgreSQL. We are absolutely NOT sure that the
> problem is inside PostgreSQL.
>
> What we are trying to understand is, first and foremost, if there are
> known cases under which PostgreSQL can truncate a file.
I would suspect either your hardware (RAID controller, hard drive, cache
etc) or your OS (kernel bug, file system bug, etc)
For instance:
http://lwn.net/Articles/215868/
documents a bug in the 2.6 linux kernel that can result in corrupted
files if there are a lot of processes accessing it at once.
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2007-06-04 21:15:19 | Re: Transactional DDL |
Previous Message | Islam Hegazy | 2007-06-04 20:59:30 | Re: debugging C functions |