Re: small smgrcreate cleanup patch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: small smgrcreate cleanup patch
Date
Msg-id AANLkTiku3T+iaN4LXa9kdBD62Peg4d0UsJVnaZdns=7r@mail.gmail.com
Whole thread Raw
In response to Re: small smgrcreate cleanup patch  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Fri, Aug 20, 2010 at 10:20 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 20/08/10 17:01, Robert Haas wrote:
>>
>> On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com>  wrote:
>>>
>>> On 20/08/10 16:30, Robert Haas wrote:
>>>>
>>>> I really like the idea of trying to use network-based storage in some
>>>> way.  Gigabit Ethernet is a big I/O channel.
>>>
>>> NFS?
>>
>> I don't particularly trust NFS to be either reliable or performant for
>> database use.  Do you?
>
> Depends on the implementation, I guess, but the point is that there's a
> bazillion network-based filesystems with different tradeoffs out there
> already. It seems unlikely that you could outperform them with something
> built into PostgreSQL.
>
> To put it other way, if you built network-based storage into PostgreSQL,
> what PostgreSQL-specific knowledge could you take advanage of to make it
> more performant/reliable? If there isn't any, I don't see the point.

PostgreSQL-specific knowledge?  Probably not.  But:

- Setting up NFS is very easy to do wrong.  I bet if you find 100
people who are running PG over NFS, 80 of them have a wrong setting
somewhere that's compromising their data integrity.
- NFS, like all other solutions in this area, is platform-specific,
and thus not available everywhere.
- We don't need a general-purpose network file system - we need
something very specific, which should therefore be able to be done in
a more lightweight fashion.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Deadlock bug
Next
From: Robert Haas
Date:
Subject: Re: security hook on authorization