RE: Error: cannot write block XX of XXXXX/XXXXX blind: resource tempo rarily unavailable - Mailing list pgsql-general

From Stock, Stuart H.
Subject RE: Error: cannot write block XX of XXXXX/XXXXX blind: resource tempo rarily unavailable
Date
Msg-id 245F5B34AF80D411AF690008C791E5B607D19248@SF-EXCH-4
Whole thread Raw
List pgsql-general
> -----Original Message-----
> From:    Larry Rosenman [SMTP:ler@iadfw.net]
> Sent:    Thursday, June 21, 2001 12:19 PM
> To:    Tom Lane
> Cc:    Stock, Stuart H.; 'pgsql-general@postgresql.org'
> Subject:    Re: [GENERAL] Error: cannot write block XX of XXXXX/XXXXX
> blind: resource tempo rarily unavailable
>
> * Tom Lane <tgl@sss.pgh.pa.us> [010621 14:16]:
> > "Stock, Stuart H." <Stuart.H.Stock@bofasecurities.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?
> What does the netapp's log say?  What version of NetApp's Data OnTap?
>
> (I use netapps, and their great!).
>
We love ours as well. ;)  It's an 820 ONTAP 6.0.1R1.  The logs are clean.
The mount options are remote/read/write/setuid which are the same mount
options being used for a Versant OODB install which is running fine.


> > > 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.
> Why should a DEDICATED NFS server have an issue with no sharing of the
> DB Stuff?
>
Our system is indeed dedicated: only a single host mounts the PostgreSQL
export and we run the backend on a single machine.

I understand that running a database over NFS can be a contentious issue so
I'll tiptoe. ;-)  Our experiences with Versant and Sybase over NFS have been
extremely positive which is why we've gone with pgsql over NFS as well
(Sybase sports NetApp "certification" whatever that is worth).   I'm not
familiar with pgsql internals or the possible differences between pgsql and
other rdbms' that might cause issues over nfs.  I did do a documentation,
usenet, and google search to look for known pgsql issues with nfs but found
very little information.

Could this issue be unrelated to NFS?  Perhaps some kind of kernel tuning
that I've neglected?

Stuart

(and I apologize for the horrific disclaimer spam)




_____________________________________________________________________
IMPORTANT NOTICES:
          This message is intended only for the addressee. Please notify the
sender by e-mail if you are not the intended recipient. If you are not the
intended recipient, you may not copy, disclose, or distribute this message
or its contents to any other person and any such actions may be unlawful.

         Banc of America Securities LLC("BAS") does not accept time
sensitive, action-oriented messages or transaction orders, including orders
to purchase or sell securities, via e-mail.

         BAS reserves the right to monitor and review the content of all
messages sent to or from this e-mail address. Messages sent to or from this
e-mail address may be stored on the BAS e-mail system.



pgsql-general by date:

Previous
From: will trillich
Date:
Subject: Re: newbie primary key problem
Next
From: Dennis
Date:
Subject: Shared Buffers