From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, tgl(at)sss(dot)pgh(dot)pa(dot)us, zhouqq(at)cs(dot)toronto(dot)edu, icub3d(at)gmail(dot)com, pgsql-admin(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] ERROR: could not read block |
Date: | 2005-11-21 23:05:57 |
Message-ID: | 20051121230556.GP19279@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-11-21 23:24:39 | Re: [ADMIN] ERROR: could not read block |
Previous Message | Qingqing Zhou | 2005-11-21 21:07:43 | Re: [ADMIN] ERROR: could not read block |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-21 23:12:50 | Re: PostgreSQL 8.1.0 catalog corruption |
Previous Message | Bob Ippolito | 2005-11-21 22:50:39 | Re: PostgreSQL 8.1.0 catalog corruption |