Re: PostgreSQL Portable

Hey,
I'm working in GIS field and I had the same problems.
Solution I found, which has been working for the past year :
virtual box on external drive !
This way you can have an independent OS (Linux for easy
postgres/postgis/whatever gis you want).

I find it very comfortable because my server is separated from guest os. So
I can take the disk and work on any pc with virtual box installed (require
admin right), and I have all GIS tools on the server, so the virtual
machine is very self contained.
It is also easy to backup (but very slow due to huge iso file).

I use a USB2 okay-ish disk. Guest win XP 64 / win seven 32 ; Host Ubuntu
12.04 32b.
About perfo : I do complex queries. Perf are OK for my use case (about same
as a dedicated XP 32bit).

Using the external disk to hold a table space is a __very__ bad idea.
As soon you do some upgrade/the disk get disconnected/anything happen, you
are really screwed.
(I had the issue. Without backup you can't do much without very strong
postgres skills)

Cheers,
Rémi-C

2014-09-10 23:50 GMT+02:00 Steve Crawford <scrawford(at)pinpointresearch(dot)com>:

> On 09/10/2014 02:00 PM, Daniel Begin wrote:
>
> First, I am a Newbie regarding PostgreSQL …
>
>
>
> I just started to look at PostgreSQL to implement a large GIS DB (1Tb).
> The data must reside in an external disk with eSATA connection and may be
> moved to different locations (and Windows desktops/laptops). I was looking
> to install PostgreSQL and PostGIS extensions on each PC (setting-up the
> proper PGDATA directory to the external disk) until I read about PostgreSQL
> and PgAdmin Portable …
>
>
>
> http://sourceforge.net/projects/pgadminportable/
>
> http://sourceforge.net/projects/postgresqlportable/
>
>
>
> Is that a viable alternative considering the expected size of the DB? Any
> comments or proposal would be appreciated J
>
> Daniel
>
>
> It appears you are looking to take the PostgreSQL data directory from
> machine to machine on an external drive. I fear you will run into some
> potential problems:
>
> 1. Performance (mentioned by others).
>
> 2. OS mismatch. Have you ensured that all client machines are running
> identical setups? The underlying files are not guaranteed portable between
> OS versions and 64/32-bit. In fact they probably won't be.
>
> 3. Backups. What happens when one user screws up the database?
>
> Perhaps you could explain further the genesis of this requirement. The
> message list is littered with questions like this asking how to implement a
> certain solution when, given an understanding of the reason the question is
> being asked, a far better solution exists. This happens even more often
> when the person asking is a "newbie."
>
> Cheers,
> Steve
>
>