From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | S Arvind <arvindwill(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Best suiting OS |
Date: | 2009-10-02 17:43:40 |
Message-ID: | alpine.GSO.2.01.0910021337280.25020@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, 2 Oct 2009, Merlin Moncure wrote:
> I know I'm in the minority here, but I _always_ compile postgresql
> myself directly from official sources. It's easy enough and you never
> know when you have to do an emergency patch or cassert build, etc.
That requires one take all of the security update responsibility yourself,
which isn't a trade-off some people want. In a lot of situations, it's
just plain easier to take minor point release updates through the main
package manager when there's a bug fix release, knowing that the project
policies will never slip something other than bug fixes into that. I
think many users will never do a patched build or even know what cassert
toggles, and really they'd shouldn't have to.
The trick I suggest people who use packaged builds get familiar with is
knowing that if you run pg_config and look for the CONFIGURE line, you'll
find out exactly what options were used by the builder of the package you
have, when they compiled the server from source for that package. If
you've been using a packaged build, but now discovered you need to use a
source one instead, you should be able to grab the source, compile with
those same options, and get a compatible server out of it.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2009-10-02 18:18:38 | Re: updating a row in a table with only one row |
Previous Message | Robert Haas | 2009-10-02 17:39:38 | Re: updating a row in a table with only one row |