Re: Alternative cluster location - Mailing list pgsql-general
From | kdebisschop@alert.infoplease.com |
---|---|
Subject | Re: Alternative cluster location |
Date | |
Msg-id | 1069089940.11764.41.camel@skilletinfopleasecom.nh.pearsoned.com Whole thread Raw |
In response to | Re: Alternative cluster location (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-general |
On Mon, 2003-11-17 at 11:07, Peter Eisentraut wrote: > Karl DeBisschop writes: > > > On linux, you may also want to consider the most recent proposed FHS, > > which suggests a top-level /srv directory used for 'data generated by > > users for the services the system offers' > > Interesting, but I'm not sure it's appropriate. Considering the examples > offered for /srv: www, ftp, rsync, cvs, it's more intended for placing > actual files there to be served to the outside. (In case of CVS that's > not quite right, admittedly.) On the other hand, database files are more > like IMAP folders, which are internal state information that can only > (reasonably) be read or written via some (possibly remote) program. I'm not sure where you read that, other than by the examples given. Were there other statements that led you to this conclusion? I read '/srv contains site-specific data which is served by this system'. If postgresql were to use this model on a Linux-FHS system, I would suggest something like: 1) config files in /etc 2) data tables in /srv 3) indexes, WAL data, temp files stay in /var/lib/pgsql This fits in with the general idea that this user data is often rather valuable, and is one of the partitions that needs to be backed up with special care (although this is also true of big parts of /var). In a typical database implementation, this is not as true of the indices, which can just be regenerated. It also provides a framework for those site that split data and indices onto different disks for performance reasons. > Maybe we should pose that question to the FHS group. It might be worth doing. Like you, I'm not sure how/if this model would appliy. But now is the time to think about how it might be applied and what implications that has for stablility and performance of the DBMS. In this case, I think it might be an overall benefit. > > Personally, I like the FHS and would prefer that the various distros > > installed postgresql in a manner more consistent with it > > I think they are doing quite well. What complaints do you have? Just that the config files for postgresql are not in /etc. This was primarily aimed at RedHat, because that is what I'm most familiar with. > > (and if necessary that the postgresql configs were modified to make that > > and easier alternative.) > > I don't think there are any problems on the configure/make side. Do you > know of any? I was recalling a thread some time ago where someone (I thought it was you) was concerned that the postgresql security model made it hard to place the config files in /etc. Or something like that. It's a very vague recollection - I referred to it of of respect for the fact that other people have thought about it more than it, rather than from any specific knowledge. -- Karl DeBisschop <kdebisschop@alert.infoplease.com> Pearson Education/Information Please
pgsql-general by date: