Date: Mon, 21 Nov 2005 17:05:57 -0600
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: Magnus Hagander <mha@sollentuna.net>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, tgl@sss.pgh.pa.us,
	zhouqq@cs.toronto.edu, icub3d@gmail.com, pgsql-admin@postgresql.org,
	pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ERROR: could not read block
Message-ID: <20051121230556.GP19279@pervasive.com>
References: <6BCB9D8A16AC4241919521715F4D8BCE92E86E@algol.sollentuna.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6BCB9D8A16AC4241919521715F4D8BCE92E86E@algol.sollentuna.se>
User-Agent: Mutt/1.5.9i

On Thu, Nov 17, 2005 at 07:56:21PM +0100, Magnus Hagander wrote:
> The way I read it, a delay should help. It's basically running out of
> kernel buffers, and we just delay, somebody else (another process, or an
> IRQ handler, or whatever) should get finished with their I/O, free up
> the buffer, and let us have it. Looking around a bit I see several
> references that you should retry on it, but nothing in the API docs.
> I do think it's probably a good idea to do a short delay before retrying
> - at least to yield the CPU for one slice. That would greatly increase
> the probability of someone else finishing their I/O...

If that makes it into code, ISTM it would be good if it also threw a
NOTICE so that users could see if this was happening; kinda like the
notice about log files being recycled frequently.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461