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

Поиск
Список
Период
Сортировка
От Purusothaman A
Тема Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL.
Дата
Msg-id 3650d0d50705240035h795f935do6312ebe0866577fb@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL.  (Richard Huxton <dev@archonet.com>)
Ответы Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL.  (Richard Huxton <dev@archonet.com>)
Список pgsql-admin
Дерево обсуждения
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@archonet.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/

В списке pgsql-admin по дате отправления:

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL.
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: [GENERAL] OIDs - file objects, are damaged by PostgreSQL.