Re: OIDs - file objects, are damaged by PostgreSQL. - Mailing list pgsql-general

From Purusothaman A
Subject Re: OIDs - file objects, are damaged by PostgreSQL.
Date
Msg-id 3650d0d50705230756g5fdf8bdava3de463eb6f82ad9@mail.gmail.com
Whole thread Raw
In response to Re: OIDs - file objects, are damaged by PostgreSQL.  (Richard Huxton <dev@archonet.com>)
Responses Re: OIDs - file objects, are damaged by PostgreSQL.
List pgsql-general
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.

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.

Usually this problem arises only after the database become large.

Any suggestion to rectify this problem would be nice of you.

Thanks.

Regards,
Purusothaman A

On 5/23/07, Richard Huxton <dev@archonet.com> wrote:
Purusothaman A wrote:
> Thanks Richard Huxton for your reply.
>
> I use client side api for uploading and downloading files.
>
> Its not happening immediately. But when database grows with data, file
> object got corrupted.

Yes, but *HOW* - is it a different file, length is different, what?

> My table structure is as follows.
>             Table "public.conf"
> Column |          Type          | Modifiers
> --------+------------------------+-----------
> key    | character varying(50)  | not null
> value  | character varying(100) |
> Indexes:
>    "conf_pkey" PRIMARY KEY, btree ("key")
>
> Content of this table is,
>         key         | value
> ---------------------+--------
> HX                  | 101800
> MASK                | 101801
> Rockey4ND           | 101802
> Threshold           | 60
> Authentication Mode | 2
> (5 rows)
>
> In the above, value of HX, MASK, Rockey4ND is 101800, 101801, 101802 (which
> was returned by lo_import());

I find it unlikely that "2" and "60" were returned by lo_import() as
OIDs available for large-objects. You've either got:
1. Some other part of your application(s) overwriting "value"
2. Old data still in "value"
3. On-disk corruption due to crashes/hardware malfunction.
4. You're not showing real values

> Actually for some peculiar reason I  kept "Value" field as var char instead
> of oid. (this could be reason?...)

Hmm - well it's clearly not right, but I don't see how it can cause
errors like this.

> This problem occurs only few weeks after uploading files.

You still haven't said precisely what the problem is.

--
   Richard Huxton
   Archonet Ltd



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

pgsql-general by date:

Previous
From: "Leif B. Kristensen"
Date:
Subject: Re: Sequential scan from simple query
Next
From: André Volpato
Date:
Subject: Re: Faster data type for one-length values