Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL.

Richard Huxton,

Thanks for your detailed reply.

I am maintaining various database of same kind in postgresql.
Here I have shown various corrupted last line of output of select * from
pg_largeobject where oid = xxxxxx; in 5 databases.

I have used '\o e:\\filename.xml' before executing query and inspected the
output in that file.

Kindly look at the end of line in all 5 outputs.
First 3 output shows few missing characters.
But last 2 output is the perfect one.

1. Output of SFRS2 database:
--------------------------------------------
101177 | 630 | ight_val></_></_></trees>\015\012 <stage_threshold>-
2.9928278923034668</stage_threshold>\015\012
<parent>23</parent>\015\012
<next>-1</next></_></stages></haarcascade_frontalface_defau
(631 rows)

2. Output of SFRS1 database:
---------------------------------------------
41642 | 630 | ight_val></_></_></trees>\015\012 <stage_threshold>-
2.9928278923034668</stage_threshold>\015\012
<parent>23</parent>\015\012
<next>-1</next></_></stages></haarcascade_frontalface_default>\015\012</openc
(631 rows)

3. Output of FASP_AVT database:
--------------------------------------------------
101800 | 630 | ight_val></_></_></trees>\015\012 <stage_threshold>-
2.9928278923034668</stage_threshold>\015\012
<parent>23</parent>\015\012
<next>-1</next></_></stages></haarcascade_frontalface_default>\015\012</openc
(631 rows)

4. Output of SFRS database: (not yet corrupted)
----------------------------------------------------------------------
24038 | 630 | ight_val></_></_></trees>\015\012 <stage_threshold>-
2.9928278923034668</stage_threshold>\015\012
<parent>23</parent>\015\012
<next>-1</next></_></stages></haarcascade_frontalface_default>\015\012</opencv_storage>\015\012
(631 rows)

5. Output of FASP_TEST database: (Not yet corrupted)
--------------------------------------------------------------------------------
106310 | 630 | ight_val></_></_></trees>\015\012 <stage_threshold>-
2.9928278923034668</stage_threshold>\015\012
<parent>23</parent>\015\012
<next>-1</next></_></stages></haarcascade_frontalface_default>\015\012</opencv_storage>\015\012
(631 rows)

Can you figure out the reason behind that.
I am waiting for your valuable suggestion.

Thanks.

Regards,
Purusothaman A

On 5/23/07, Richard Huxton <dev(at)archonet(dot)com> wrote:
>
> 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
>

--
http://PurusothamanA.wordpress.com/