Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] ERROR: could not read block

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <zhouqq(at)cs(dot)toronto(dot)edu>,<mha(at)sollentuna(dot)net>,"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: <icub3d(at)gmail(dot)com>,<pgsql-admin(at)postgresql(dot)org>,<pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [HACKERS] ERROR: could not read block
Date: 2005-11-17 20:49:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-hackers
A couple clarifications:

There were only a few network sockets open.

I'm told that the eventlog was reviewed for any events which
mgiht be related to the failures before it was cleared.  They
found none, so that makes it fairly certain there was no 2020


>>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>  >>>
There weren't a large number of connections -- it seemed to be
that the one big update query, by itself, would do this.  It seemed
to get through a lot of rows before failing.  This table is normally
"insert only" -- so it would likely be getting most or all of the space
for inserting the updated rows from extending the table.  Also, the
only reasonable plan for this update would be a table scan, so
it is possible that the failure occurred some time after the scan got
to rows added by the update statement.

It appears that the techs cleared the eventlog when they
reconfigured the machine, so I can no longer check for events
from the failures.   :-(


>>> "Magnus Hagander" <mha(at)sollentuna(dot)net>  >>>
> None of this seems material, however.  It's pretty clear that 
> the problem was exhaustion of the Windows page pool.  Our 
> Windows experts have reconfigured the machine (which had been 
> tuned for Sybase ASE).  Their changes have boosted the page 
> pool from 20,000 entries to 180,000 entries.  We're 
> continuing to test to ensure that the problem is not showing 
> up with this configuration; but, so far, it looks good.

Nope, with these numbers it doesn't. I was looking for a reason as to
why it would exhaust the pool - such as a huge number of connections.
Which doesn't appear to be so :-(

Another thing that will affect this is if you have a lot of network
sockets open. Anything like that?

BTW; do you get any eventid 2020 in your eventlog?

> If we don't want to tell Windows users to make highly 
> technical changes to the Windows registry in order to use 
> PostgreSQL, it does seem wise to use retries, as has already 
> been discussed on this thread.

Yeah, I think it's at least worth a try at that.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2005-11-17 21:09:09
Subject: Re: Improving count(*)
Previous:From: Rod TaylorDate: 2005-11-17 19:55:09
Subject: Re: Improving count(*)

pgsql-admin by date

Next:From: Andrew SullivanDate: 2005-11-17 21:24:39
Subject: Re: restore challenge
Previous:From: Kevin GrittnerDate: 2005-11-17 19:54:03
Subject: Re: [HACKERS] ERROR: could not read block

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group