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
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
> 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 to this silliness, they'll be thinking hard
> about how to get Oracle out and something reliable in.
>> 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 configuration and are a good 10-20 times
>> faster than the local disk performance along with the quick
>> take-over capability if a system goes belly up.
> Oracle stores more state to the disk than PostgreSQL does, which has
> significant down sides. There are more effective ways of handling
> uptime requirements than jamming NFS into the picture. Maybe it's
> just my failure of imagination, but I can't think of a *less*
> effective one.
>> I'll try to isolate this problem with a simple C program to tell me
>> what software layer to look at. Hopefully it's just a configuration
> It's not. The issue is that NFS is broken garbage from a DBMS, and,
> it's pretty easy to argue, just about any other perspective.
>> Tom Lane-2 wrote:
>> > austijc <jaustin(at)jasononthe(dot)net> writes:
>> >> The question is can anyone more familiar with this tell me what's
>> >> on
>> >> here? I don't know if this is a Postgres, Sun, or NetApp issue.
>> >> it
>> >> be a work around for an old Linux bug causing an issue with acceptable
>> >> behavior of the NetApp device?
>> > People who try to run databases over NFS usually regret it eventually
>> > All I can say is that this error message has never before been reported
>> > by anyone who wasn't exposed to that lseek-inconsistency kernel bug.
>> > I am not finding it too hard to believe that NFS might be vulnerable to
>> > similar misbehavior.
>> > regards, tom lane
>> > --
>> > Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-bugs
>> View this message in context:
>> Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
>> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
>> To make changes to your subscription:
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
View this message in context: http://www.nabble.com/ERROR%3A--unexpected-data-beyond-EOF-in-block-XXXXX-of-relation-%22file%22-tp19680438p19728120.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
In response to
pgsql-bugs by date
|Next:||From: Peter Eisentraut||Date: 2008-09-29 21:47:40|
|Subject: Re: ERROR: unexpected data beyond EOF in block XXXXX of relation
|Previous:||From: David Fetter||Date: 2008-09-29 17:16:31|
|Subject: Re: ERROR: unexpected data beyond EOF in block XXXXX ofrelation "file"|