BUG #3303: Postgresql damages file objects when it grows with more file objects.

The following bug has been logged online:

Bug reference: 3303
Logged by: Purusothaman A
Email address: purusothaman(dot)a(at)gmail(dot)com
PostgreSQL version: 8.1.3
Operating system: Windows XP
Description: Postgresql damages file objects when it grows with more
file objects.
Details:

The below output shows clearly that (same file object in different
databases) the last chunk differs in its length.

You notice that the string
"</haarcascade_frontalface_default>\015\012</opencv_storage>\015\012" is
missing some characters in SFRS2, SFRS1 and FASP_AVT database outputs.

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_frontal
face_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_frontal
face _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 "</opencv_storage>" strings? What could have caused to
damage that part?

This problem happens after database files objects grows periodically, cannot
reproduce this bug immediately.