Purusothaman A wrote:
> 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.
Yep, spotted that. Hence asking for the length, and it looks like...
> loid | pageno | length
> --------+--------+--------
> 101177 | 630 | 181
> 41642 | 630 | 193
> 101800 | 630 | 193
> 24038 | 630 | 205
The data has just been truncated rather than corrupted.
> Is it bug in Posstgresql or is they any way to solve this problem.
Well, something is setting the length too short on these entries. Can
you tell me whether the following statements are all correct?
1. Each database is on a separate machine (that would rule out a
hardware problem)
2. All systems are running on Windows 2000/XP/2003.
3. All systems are version 8.2.4 (if not, please give details)
4. You upload the data with lo_import (once) and download it with
lo_export (many times) and don't alter it in-between.
5. Where the data has been truncated, you know for a fact you downloaded
it OK before (or do you just suspect it was OK?)
If you're not changing the data, and you know it was OK at some point
then there are only two things I can think of:
1. A hardware problem (which we might rule out above)
2. A bug in PostgreSQL's vacuum code
Nothing else should be writing to those blocks.
If it looks like a bug in vacuum, we can try to reproduce it, and also
examine the actual contents of the on-disk files (to see if the data is
there on the disk or not). I'll also copy this message over to the
hackers list and see what the developers have to say.
--
Richard Huxton
Archonet Ltd