From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Purusothaman A <purusothaman(dot)a(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL. |
Date: | 2007-05-23 15:47:40 |
Message-ID: | 4654621C.8010700@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
Purusothaman A wrote:
> Dear Richard Huxton,
>
> Thanks for your quick reply.
>
> only the first 3 values(HX, MASK, Rockey4ND) are file object's oid value.
> the other two are are not oid values.
Umm - OK. Can I suggest perhaps having different tables for different
types of data?
> I have shown original output values displayed by postgresql client.
>
> I can explain more.
>
> 1. HX is a XML file. after downloading that file I opened that file in word
> pad application.
> In that I have noticed that nearly 20 characters of last line lost.
> 2. Rockey4ND is a dll file. I was unable to use that dll in my application.
>
> In both cases, I checked file size. Corrupted files are smaller when
> compare
> to the original one what I uploaded to postgresql.
OK, so the data seems OK up until that point?
> Usually this problem arises only after the database become large.
I can't think of any reason why that would make a difference. But, this
does give us a clue. If you have successfully downloaded these files
before, that rules out certain forms of failure.
> Any suggestion to rectify this problem would be nice of you.
Reading through recent release notes, I can't see anything mentioning
lo_import/export, large objects or similar.
http://www.postgresql.org/docs/8.2/static/release-8-2-4.html
Well, your data is stored in pg_largeobject. If you run a SELECT you can
see how it's broken into chunks.
SELECT loid,pageno,length(data) FROM pg_largeobject ;
On my system, a full chunk is 2048 bytes long. What does the last chunk
of your HX object (101800) look like? Is it a full chunk? Does it end
where your downloaded file ends?
If the data is OK in pg_largeobject then we know we have a problem with
lo_export-ing or saving to a file.
If not, then we know we have a problem with something deleting or
overwriting chunks in pg_largeobject. That would surprise me, because I
don't think there's anything special about pg_largeobject - it's just a
table with chunks of bytea data in it.
Just to recap - you're using lo_import() and lo_export from C (or at
least via libpq) to read/write these files directly to your filesystem.
You've not been seeing crashes and you don't think you've got hardware
problems.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Jair Elton Batista | 2007-05-24 02:46:21 | Performance Monitor |
Previous Message | Purusothaman A | 2007-05-23 14:56:21 | Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL. |
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2007-05-23 15:51:16 | Re: Tsearch2: upgrading from postgres 8.1.x to 8.2.x |
Previous Message | Alvaro Herrera | 2007-05-23 15:22:26 | Re: Faster data type for one-length values |