But the same code worked when I inserted around 2500 images in the database. After that it started crashing. So , I don't think it's because of error in the code. Can u suggest some other possible reasons and also why is it crashing at call to memcpy().





Tom Lane <tgl@sss.pgh.pa.us> wrote: Ashish Goel
writes:
> We have a following table xyz( id int , fname varchar(50), img image)
> where image is a data type we have created similar to lo.
> ...
> Can somebody suggest us what might be the cause of error and what can we do to resolve it ?

Incorrect code in your custom datatype, almost certainly. Check
computations of memory size allocations, for example. Test it in
a backend compiled with --enable-cassert.

regards, tom lane




---------------------------------
All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.


---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail.

Hi, Ashish,

Ashish Goel wrote:
> But the same code worked when I inserted around 2500 images in the
> database. After that it started crashing.

Testing can never prove that there are no bugs.

It's like the proof that all odd numbers above 1 are prime:

3 is prime, 5 is prime, 7 is prime, so I conclude that all odd numbers
above 1 are prime.


So , I don't think it's
> because of error in the code. Can u suggest some other possible reasons
> and also why is it crashing at call to memcpy().

- broken hardware
- compiler bugs
- bugs in PostgreSQL

But without having seen your code, I tend to assume that it's something
like a wrong length flag in some corner case in your code.
...

Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFM3WiyHQIGEs7eeARAwshAKCrP+wQfOowF3RihUS1Qm c1tDFTVACeIIwI
OPeSjEqrBNLH5euOtPCzB6A=
=HozW
-----END PGP SIGNATURE-----

Hi all,

I am sorry but I forgot to mention that in the database schema we are maintaining referrences to the main table xyz(int id, img image, fname varhcar(50))

There are around 14 tables referrencing this table . The referrences are being made to the column id.

The code works well if we don't maintain the referrences but when we include the referrences then the database crashes somewhere between 2500-3000 transactions.

So could this problem be due to the multiple referrences being made to the same table ?

Markus Schaber <schabi@logix-tt.com> wrote: Hi, Ashish,

Ashish Goel wrote:
> But the same code worked when I inserted around 2500 images in the
> database. After that it started crashing.

Testing can never prove that there are no bugs.

It's like the proof that all odd numbers above 1 are prime:

3 is prime, 5 is prime, 7 is prime, so I conclude that all odd numbers
above 1 are prime.


So , I don't think it's
> because of error in the code. Can u suggest some other possible reasons
> and also why is it crashing at call to memcpy().

- broken hardware
- compiler bugs
- bugs in PostgreSQL

But without having seen your code, I tend to assume that it's something
like a wrong length flag in some corner case in your code.
....

Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org




---------------------------------
Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business.

Hi, Ashish,

Ashish Goel wrote:

> I am sorry but I forgot to mention that in the database schema we are
> maintaining referrences to the main table xyz(int id, img image, fname
> varhcar(50))
>
> There are around 14 tables referrencing this table . The referrences are
> being made to the column id.
>
> The code works well if we don't maintain the referrences but when we
> include the referrences then the database crashes somewhere between
> 2500-3000 transactions.
>
> So could this problem be due to the multiple referrences being made to
> the same table ?

I doubt so.

Foreign key references are among the basics of SQL, they're pretty well
tested.

Could you try to replace your image type e. G. with bytea for your test
purposes, and see, whether it crashes, too?

HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNI7tyHQIGEs7eeARA9U/AJ40XxgEKHAzVqA+mZbrsbsFWxyJNgCg+19u
7ndpeE3IlZspot6UxxtJSLU=
=0gsh
-----END PGP SIGNATURE-----

Markus Schaber <schabi@logix-tt.com> writes:
> Ashish Goel wrote:
>> The code works well if we don't maintain the referrences but when we
>> include the referrences then the database crashes somewhere between
>> 2500-3000 transactions.
>>
>> So could this problem be due to the multiple referrences being made to
>> the same table ?

> I doubt so.
> Foreign key references are among the basics of SQL, they're pretty well
> tested.

I'm betting that this is a memory-clobber problem in that custom datatype.
The reason the symptoms come and go when varying unrelated stuff is that
it might be chancing to clobber momentarily-unused memory rather than
live data structures. (In the above example, the queue of pending FK
trigger events is likely what got clobbered.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org