Re: Tablespaces - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Tablespaces
Date
Msg-id 200403081730.i28HUfa20453@candle.pha.pa.us
Whole thread Raw
In response to Re: Tablespaces  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-hackers
Andrew Sullivan wrote:
> On Mon, Mar 08, 2004 at 02:07:35AM +0200, Marko Karppinen wrote:
> > One thing to keep in mind is that system administrators don't see
> > symlinks as being informational -- they see them as the actual UI
> > for the redirection in question. So their expectation is that they'll
> > be able to move the actual directory around at will (as long as they
> > update the symlink to match).
> 
> This is a good point.  It's worth keeping in mind, too, that in large
> shops, the DBAs and the sysadmins often are in separate departments
> with separate management, precisely because the database system has
> traditionally been somewhat divorced from the OS (as an aside, I
> suspect that this sort of separation is part of the reason for the
> popularity of raw filesystems among DBAs.  Even if they didn't
> provide better speed, it's just preferable not to have to involve
> another department).  System administrators in such places have been
> known to decide to "reorganise the disks", assuming that the database
> just has its own home.  For such a sysadmin, a pile of symlinks would
> be fair game for reorganisation.

Agreed.  I think the idea is to use lstat to query the symlink, rather
than storing that information in the database.  My idea was to create an
lstat server-side function that could be used by pg_dump and friends.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: raising the default default_statistics_target
Next
From: Joe Maldonado
Date:
Subject: Re: question about selecting across multiple dbs