Re: PostgreSQL server embedded in NAS firmware?

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Andrew Barnham <andrew(dot)barnham(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: PostgreSQL server embedded in NAS firmware?
Date: 2012-09-06 23:19:42
Message-ID: CAOR=d=0gZRx_BDUmg=RC-BLbo7kz_iL3WidEeyU3KhxbVqmCiw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

That shouldn't really matter. Either the db is just on the NAS in
which case as long as pg compiles on it then the client on the main
unit shouldn't matter, or the data is just stored there and the db is
on the main unit, client and all and again it wouldn't matter.

But the client and server do NOT have to be the same architecture to
work for sure.

On Thu, Sep 6, 2012 at 4:40 PM, Andrew Barnham <andrew(dot)barnham(at)gmail(dot)com> wrote:
> Scratch that. An immediate show stopping pitfall occurs to me: the necessity
> to match CPU/OS Architecture between primary server and replicate target.
> Doubtful that there are any consumer NAS products out there running linux on
> 64bit/intel
>
>
> On Fri, Sep 7, 2012 at 8:23 AM, Andrew Barnham <andrew(dot)barnham(at)gmail(dot)com>
> wrote:
>>
>> Hi
>>
>> I currently run a modest streaming replication target on a cheap, single
>> disk ASUS media center; replicating a 100GB PG database.
>>
>> I want to add RAID via a consumer grade NAS device.
>>
>> As far as I can tell consumer grade NAS devices these days appear to be
>> fairly rich & flexible embedded lniux/freebsd systems.
>>
>> Has anyone had any experience with running postgresql on the NAS device
>> itself? Which products? Any traps or pitfalls or integrity concerns about
>> such an arrangement?
>>
>> Andrew
>
>

--
To understand recursion, one must first understand recursion.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Janes 2012-09-07 00:06:27 Re: Multiple indexes, huge table
Previous Message Aram Fingal 2012-09-06 23:17:57 Re: Multiple indexes, huge table