Questions about connection clean-up and "invalid page header"

From: Herouth Maoz <herouth(at)unicell(dot)co(dot)il>
To: pgsql-general(at)postgresql(dot)org
Subject: Questions about connection clean-up and "invalid page header"
Date: 2010-01-24 10:17:11
Message-ID: 201001241217.11751.herouth@unicell.co.il
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi Everybody.

I have two questions.

1. We have a system that is accessed by Crystal reports which is in turned
controlled by another (3rd party) system. Now, when a report takes too long or
the user cancels it, it doesn't send a cancel request to Postgres. It just
kills the Crystal process that works on it.

As a result, the query is left alive on the Postgres backend. Eventually I get
the message "Unexpected End of file" and the query is cancelled. But this
doesn't happen soon enough for me - these are usually very heavy queries, and
I'd like them to be cleaned up as soon as possible if the client connection
has ended.

Is there a parameter to set in the configuration or some other means to
shorten the time before an abandoned backend's query is cancelled?

2. I get the following message in my development database:

vacuumdb: vacuuming of database "reports" failed: ERROR: invalid page header
in block 6200 of relation "rb"

I had this already a couple of months ago. Looking around the web, I saw this
error is supposed to indicate a hardware error. I informed my sysadmin, but
since this is just the dev system and the data was not important, I did a
TRUNCATE TABLE on the "rb" relation, and the errors stopped...

But now the error is back, and I'm a bit suspicious. If this is a hardware
issue, it's rather suspicious that it returned in the exact same relation
after I did a "truncate table". I have many other relations in the system,
ones that fill up a lot faster. So I suspect this might be a PostgreSQL issue
after all. What can I do about this?

We are currently using PostgreSQL v. 8.3.1 on the server side.

TIA,
Herouth

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ovid 2010-01-24 13:43:10 Self-referential records
Previous Message Alban Hertroys 2010-01-24 09:51:51 Re: Recursion in triggers?

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-01-24 11:22:55 Re: further explain changes
Previous Message KaiGai Kohei 2010-01-24 09:32:30 Re: restructuring "alter table" privilege checks