From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Stock, Stuart H(dot)" <Stuart(dot)H(dot)Stock(at)bofasecurities(dot)com> |
Cc: | "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Error: cannot write block XX of XXXXX/XXXXX blind: resource tempo rarily unavailable |
Date: | 2001-06-21 18:01:05 |
Message-ID: | 22238.993146465@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Stock, Stuart H." <Stuart(dot)H(dot)Stock(at)bofasecurities(dot)com> writes:
> I am running Postgresql 7.1.1 compiled with GCC 2.95.2 on a Sun 220
> Solaris 2.8 box and am experiencing the following error:
> DEBUG: mdblindwrt: close() failed: Resource temporarily unavailable
> ERROR: cannot write block 44 of 2139949/2405766 blind: Resource temporarily
> unavailable
Ugh. Seems like you are running out of kernel-level resources. How
could a close() fail, anyway?
> The database resides on an NFS mount served by a Network Appliance.
We generally don't recommend running production databases over NFS.
This seems to be a perfect example of why not to.
You might be able to make this particular problem go away by decreasing
MaxBackends or decreasing the number of files each individual backend
will try to open --- the latter would take some hand hacking of
pg_nofile() in src/backend/storage/file/fd.c. But I suspect you will
continue to encounter grief until you get rid of the NFS mount.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Buttafuoco | 2001-06-21 18:04:18 | WAL failure? |
Previous Message | Stock, Stuart H. | 2001-06-21 17:14:41 | Error: cannot write block XX of XXXXX/XXXXX blind: resource tempo rarily unavailable |