Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 81B98635B74 for ; Tue, 9 Mar 2010 10:32:39 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 84315-03-2 for ; Tue, 9 Mar 2010 14:32:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from is.rice.edu (is.rice.edu [128.42.42.24]) by mail.postgresql.org (Postfix) with ESMTP id B3B2B635B93 for ; Tue, 9 Mar 2010 10:32:05 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by is.rice.edu (Postfix) with ESMTP id 869E34181C; Tue, 9 Mar 2010 08:34:59 -0600 (CST) Received: from is.rice.edu ([127.0.0.1]) by localhost (it.is.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17636-04; Tue, 9 Mar 2010 08:34:53 -0600 (CST) Received: by is.rice.edu (Postfix, from userid 18612) id 81A4441819; Tue, 9 Mar 2010 08:34:53 -0600 (CST) Date: Tue, 9 Mar 2010 08:34:53 -0600 From: Kenneth Marshall To: Ben Kim Cc: Scott Marlowe , pgsql-admin@postgresql.org Subject: Re: linux standard layout Message-ID: <20100309143453.GG19562@it.is.rice.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: by amavis-2.2.1 at is.rice.edu X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/64 X-Sequence-Number: 33863 Hi Ben, If you must use a VMware server for your databases, please run some "pull-the-power-plug" tests on your system to ensure that your data integrity is maintained. Virtual machines can sometimes cache filesystem updates in the name of performance with disasterous consequences to your filesystems and databases. Cheers, Ken On Tue, Mar 09, 2010 at 08:18:21AM -0600, Ben Kim wrote: > > Thanks all. > > I cannot change the decision on vmware or layout, but it's great to know > that the rpm way is a valid one. > > I appreciate all inputs. > > > > Regards, > > Ben Kim > > > On Mon, 8 Mar 2010, Scott Marlowe wrote: > >> On Mon, Mar 8, 2010 at 10:31 PM, Ben Kim wrote: >>> Dear list, >>> >>> I have about 20 postgresql databases, about 3-4 GB in total. >>> >>> We are moving them from Solaris/SPARC to a linux based virtual machine. >>> >>> I don't like the VMWare environment, but it's not my choice, and assuming >>> the cpu load is ok, will there be any benefits if I put each database on >>> separate partitions, vs. simply using the one data directory? >> >> What reasoning was given for putting your database server in a >> virutalizeed environment? >> >>> Also, how is using standard rpm, with its standard layout >>> (/var/lib/pgsql, >>> /usr/lib/pgsql, ...), generally regarded? ( vs. compiling everything ?) >>> Does >>> anyone think using the rpm is unprofessional or something that only >>> beginners will do? >>> >>> I have someone who opposes the use of standard rpms (even yums) for this >>> reason. I thought I'd check out how it is received professionally. >> >> Sounds like a religious argument. I mostly used packages, unless I >> can't. (i.e. two different versions on RH at the same time) >> >>> I ask the question because sometimes I feel uneasy mixing rpms and source >>> compilation. >> >> Worry more about accidentally having two different versions of the >> same lib linked to various executables. It's easy to do with things >> like mysql and apache and php and zlib. >> >>> If I compile something from the source, sometimes I see a boundary >>> condition >>> - like, if I already have DBI from a standard rpm, it expects postgresql >>> library at a certain location - making me wonder whether I should remove >>> the >>> DBI rpm and compile it also from the source, or whether I should use >>> standard rpms for postgresql as well. (DBI may not be a good example.) >>> >>> In general I didn't have any problems yet with standard rpms and I can >>> make >>> the rpms work if there's a problem, but I may be missing something. >> >> My advice: >> >> put postgresql on its own, powerful, reliable non-virtualized server. >> Demand that the person who wants to virtualize it justify their >> decision with more than hand-wavy methodologies. Use packages unless >> you're on RPM and you need > 1 version of pgsql. Even if you need to >> compile some tarball against the packages, it's still easier to >> maintain than to install it all from source. >> > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin >