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

Richard Huxton,

In my system also its 2048 bytes chunk.

The below output shows clearly that the last chunk differs in its length.

You might have noticed in my previous mail that the string
"</haarcascade_frontalface_default>\015\012</opencv_storage>\015\012" is
missing some characters in SFRS2, SFRS1 and FASP_AVT database outputs.
Have a look at it, In this mail I have bolded the corrucpted part.

sfrs2=> select loid, pageno, length(data) from pg_largeobject where loid =
101177 and pageno = 630;
loid | pageno | length
--------+--------+--------
101177 | 630 | 181
(1 row)

sfrs1=> select loid, pageno, length(data) from pg_largeobject where loid =
41642 and pageno = 630;
loid | pageno | length
-------+--------+--------
41642 | 630 | 193
(1 row)

fasp_avt=> select loid, pageno, length(data) from pg_largeobject where loid
= 101800 and pageno = 630;
loid | pageno | length
--------+--------+--------
101800 | 630 | 193
(1 row)

sfrs=> select loid, pageno, length(data) from pg_largeobject where loid =
24038 and pageno = 630;
loid | pageno | length
-------+--------+--------
24038 | 630 | 205
(1 row)

fasp_test=> select loid, pageno, length(data) from pg_largeobject where loid
= 106310 and pageno = 630;
loid | pageno | length
--------+--------+--------
106310 | 630 | 205
(1 row)

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)

Have you noticed the bolded strings? What could have caused to damage that
part?

Is it bug in Posstgresql or is they any way to solve this problem.

Thanks.

Regards,
Purusothaman A

On 5/24/07, Richard Huxton <dev(at)archonet(dot)com> wrote:
>
> Purusothaman A wrote:
> > 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:
> > 2. Output of SFRS1 database:
> > 3. Output of FASP_AVT database:
>
> Let's have a look at the last few bytes of these three rows. For
> example, below is a very short file that finishes with "end<NL>".
>
> SELECT loid,pageno,length(data),encode(data, 'hex') FROM pg_largeobject
> WHERE loid=340161 AND pageno=0;
> loid | pageno | length | encode
>
> --------+--------+--------+----------------------------------------------------------------
> 340161 | 0 | 31 |
> 54686973206973206120746573742066696c650a6c696e6520320a656e640a
> (1 row)
>
>
> It doesn't seem to be random garbage at the end of your rows, so lets
> see what it is.
>
> Oh - things we can rule out:
> 1. Index corruption. We're not missing the last row.
>
> Adding the length check above will show us if the row is truncated or
> full of spaces.
>
> --
> Richard Huxton
> Archonet Ltd
>

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