buggy kernels / unexpected data beyond EOF in block xxxxxxx

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?
LVL 13
R7AFAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

cminearCommented:
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
R7AFAuthor Commented:
We moved the database to another server, upgraded that server to Postgresql 8.4, and now the problems seem to be disappeared!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
PostgreSQL

From novice to tech pro — start learning today.