On 6/2/07, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
"Paolo Bizzarri" <pibizza@xxxxxxxxx> writes: > On 6/2/07, Tom Lane <tgl@xxxxxxxxxxxxx> 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.
