Solved

buggy kernels / unexpected data beyond EOF in block xxxxxxx

Posted on 2009-07-16
2
1,566 Views
Last Modified: 2012-05-07
We have the following problem on our database server when executing a (quite heavy) sql query.

############################
select count(*) from pqrs();
ERROR:  unexpected data beyond EOF in block xxxxxxx of relation "properties_xyz"
HINT:  This has been seen to occur with buggy kernels; consider updating your system.
CONTEXT:  SQL statement "UPDATE properties_xyz SET abc_option_id =  $1  WHERE id =  $2 "
PL/pgSQL function "pqrs" line 63 at SQL statement

********** Error **********

ERROR: unexpected data beyond EOF in block xxxxxxx of relation "properties_xyz"
SQL status:XX000
Aanwijzing:This has been seen to occur with buggy kernels; consider updating your system.
############################

The serverload becomes critical after some time.

System info:

- Postgres 8.2.12
- Linux: Red Hat 4.1.2-12 (64 bits)

Do you have any idea what causes this and how to solve it?
0
Comment
Question by:R7AF
2 Comments
 
LVL 12

Assisted Solution

by:cminear
cminear earned 500 total points
Comment Utility
The best answer is likely as the HINT suggests: perform an upgrade of the kernel.  What kernel are you running? (Run 'uname -a' and paste results in.)  In external mailing lists, the problem has been resolved by moving from SLES 2.6.5-7.244 to 2.6.5-7.282 (which of course doesn't help you with Redhat kernel versions).  Redhat 4.7 seems to have a base kernel of 2.6.9-78, while Redhat 5.3 seems to have 2.6.18-128.  (I won't guarantee that either of these kernel versions have the specific fix for the kernel bug you are likely hitting, but they probably do.)

If you have a Redhat support contract, I would recommend that you work with them on the best option for upgrading the kernel.  If you do not, investigate an upgrade on a test server on your own.

If a system upgrade is totally out of the question, you may be able to rework the query so that it doesn't hit the bug.  However, this would be a hit or miss fix, and only temporary.  You would almost be better if you schedule the query only during low-load periods (although you seem to indicate that the query itself generates the load, so this may be a non-starter for a work-around).
0
 
LVL 13

Accepted Solution

by:
R7AF earned 0 total points
Comment Utility
We moved the database to another server, upgraded that server to Postgresql 8.4, and now the problems seem to be disappeared!
0

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Many developers have database experience, but are new to PostgreSQL. It has some truly inspiring capabilities. I have several years' experience with Microsoft's SQL Server. When I began working with MySQL, I wanted a quick-reference to MySQL (htt…
Shadow IT is coming out of the shadows as more businesses are choosing cloud-based applications. It is now a multi-cloud world for most organizations. Simultaneously, most businesses have yet to consolidate with one cloud provider or define an offic…
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

7 Experts available now in Live!

Get 1:1 Help Now