Solved

buggy kernels / unexpected data beyond EOF in block xxxxxxx

Posted on 2009-07-16
2
1,638 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
ID: 24871948
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
ID: 24893470
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

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
As technology users and professionals, we’re always learning. Our universal interest in advancing our knowledge of the trade is unmatched by most industries. It’s a curiosity that makes sense, given the climate of change. Within that, there lies a…
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

696 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