Re: Corruption of files in PostgreSQL - Mailing list pgsql-general

From Paolo Bizzarri
Subject Re: Corruption of files in PostgreSQL
Date
Msg-id 5213d1d20706021211l29fae74q4faca05f3687aa2e@mail.gmail.com
Whole thread Raw
In response to Re: Corruption of files in PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Corruption of files in PostgreSQL  ("Michael Nolan" <htfoot@gmail.com>)
Re: Corruption of files in PostgreSQL  (Scott Marlowe <smarlowe@g2switchworks.com>)
List pgsql-general
On 6/2/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Paolo Bizzarri" <pibizza@gmail.com> writes:
> > On 6/2/07, Tom Lane <tgl@sss.pgh.pa.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 don't have the time to try to
> reverse-engineer a test case from your rather vague description, whereas
> I suppose you can make one by stripping down code you've already got.

I was not asking for a reverse engineering of a test case. I will try
to provide an example, but the problem is, without knowing what to
see, that I could omit fundamental details.

> The sub-text here is that I don't really believe that lo_import and
> lo_export in themselves are broken.  There must be some extra factor ---
> something else you are doing, or something in your environment ---
> contributing to the bug.

I certainly agree with you. I was asking what to see and what to check.

> Thus, the odds of someone else building a
> usable test case from scratch aren't that good, and being able to
> reproduce the failure outside your environment is an essential step.

I agree with you. I was not hoping for this. At the same time, I was
asking an help for what to see, so that I can reproduce a test case.

As an alternate, I can suggest to download and install PAFlow, but I
understand it is a rather large application....

Best regards.

Paolo Bizzarri
Icube S.r.l.

pgsql-general by date:

Previous
From: Ron Johnson
Date:
Subject: Re: Transactional DDL
Next
From: PFC
Date:
Subject: Re: Transactional DDL