postgres database crashed
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.
so when we executed an insert query on the following table :-
insert into xyz VALUES (2541, '/home/ravi/jdbc/2_down/76.jpg', '76.jpg');
It works well for nearly 2500 images but from there onwards we obtained the following error and the database crashes.
this is the bt we obtained on using gdb with the postgres process
#0 0x00313bbc in memcpy () from /lib/libc.so.6
#1 0x0819496d in datumCopy ()
#2 0x0812d202 in copyObject ()
#3 0x08151c49 in eval_const_expressions_mutator ()
#4 0x08150c2f in expression_tree_mutator ()
#5 0x08151c49 in eval_const_expressions_mutator ()
#6 0x08150ece in expression_tree_mutator ()
#7 0x08151c49 in eval_const_expressions_mutator ()
#8 0x08152818 in eval_const_expressions ()
#9 0x081487d8 in preprocess_expression ()
#10 0x08149a04 in subquery_planner ()
#11 0x08149e56 in planner ()
#12 0x0817c25c in pg_plan_query ()
#13 0x0817c8d2 in pg_plan_queries ()
#14 0x0817e135 in PostgresMain ()
#15 0x0815b6e5 in ServerLoop ()
#16 0x0815c459 in PostmasterMain ()
#17 0x08128f48 in main ()
this is the LOG obtained
LOG: server process (PID 2499) was terminated by signal 11
(gdb) LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2006-10-10 23:40:05 IST
LOG: checkpoint record is at 0/14B37B98
LOG: redo record is at 0/14B37B98; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 210546; next OID: 851968; next MultiXactId: 1
LOG: database system was not properly shut down; automatic recovery in progress
FATAL: the database system is starting up
LOG: record with zero length at 0/14B37BD8
LOG: redo is not required
LOG: database system is ready
LOG: transaction ID wrap limit is 1073952152, limited by database "benchmark"
Can somebody suggest us what might be the cause of error and what can we do to resolve it ?
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Ashish Goel <postgres_help@yahoo.com> 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
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.
Import Notes
Resolved by subject fallback
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(). I have also checked the memory allocations , and i don't find problem there.
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
---------------------------------
How low will we go? Check out Yahoo! Messenger�s low PC-to-Phone call rates.
Did you follow Tom's suggestion of trying with a postgres configured with
--enable-cassert ?
cheers
andrew
Ashish Goel wrote:
Show quoted text
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(). I have also checked the memory
allocations , and i don't find problem there.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.
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
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
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