David Fetter wrote:
On Sun, Sep 28, 2008 at 11:51:49AM -0700, austijc wrote:
That's going to be a problem for the continued viability of
Postgres.
Funny, I thought running a DBMS over a known-unreliable storage system
was a problem for the continued viability of Oracle. When, not if,
people l
Okay, I see the maturity level is too low here. I'll take this elsewhere.
If anyone has a similar problem and would like to know the status please
email me.
David Fetter wrote:
>
> On Sun, Sep 28, 2008 at 11:51:49AM -0700, austijc wrote:
>>
>> That's going to be a problem for the continued
On Sun, Sep 28, 2008 at 11:51:49AM -0700, austijc wrote:
>
> That's going to be a problem for the continued viability of
> Postgres.
Funny, I thought running a DBMS over a known-unreliable storage system
was a problem for the continued viability of Oracle. When, not if,
people lose enough data t
That's going to be a problem for the continued viability of Postgres.
Clustered systems using a NAS for data is a pretty common configuration
these days. Oracle specifically supports it and even complains if your NFS
mount options are not correct. Our Oracle DBs run great in this same
configur
austijc <[EMAIL PROTECTED]> writes:
> The question is can anyone more familiar with this tell me what's going on
> here? I don't know if this is a Postgres, Sun, or NetApp issue. Could it
> be a work around for an old Linux bug causing an issue with acceptable
> behavior of the NetApp device?
P
Configuration:
Postgres 8.3.1
Solaris 10 Sparc System NFS mounting the database directory from a NetApp
2020 NAS device.
Mount options:
rw,bg,hard,rsize=32768,wsize=32768,vers=3,forcedirectio,nointr,proto=tcp,suid
Error:
ERROR: unexpected data beyond EOF in block 315378 of relation "file"
HI
