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 <email@example.com> 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 (firstname.lastname@example.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 (email@example.com)
>> To make changes to your subscription:
> David Fetter <firstname.lastname@example.org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: email@example.com
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
> Sent via pgsql-bugs mailing list (firstname.lastname@example.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.