Обсуждение: postgres source code installation vs rpm based installation

On 6/4/19 3:00 PM, Pavan Kumar wrote:
> Hello Experts,
>
> I have couple of questions on postgres installation.
>
> 1. which way of installation is better ? source code or rpm based ?
> 2. for instance , If we need to install same version postgres on multiple 
> times on same server. how do we need to handle this with rpm ?
> 3. If I go with source code installation, in case we need to upgrade OS(6 
> to 7) , do we need to recompile existing postgres binaries ?

Are you a Windows DBA with no Linux or Postgres experience?  (I ask that so 
that we know "where you are" in regards to installing software on Linux.)

-- 
Angular momentum makes the world go 'round.

> On Jun 4, 2019, at 2:49 PM, Pavan Kumar <pavan.dba27@gmail.com> wrote:
>
> I am  not Windows DBA.   I have very good experience on Linux and working on postgres.
> I installed postgres in both way's rpm based and source code installation.
> I prefer source code for below reason
>        I will have control on postgres software location
>        few parameter I can modify with source code installation (like wal-segsize).
>        I can install same version  postgres on multiple times as per our need.

You are thinking clearly ;-)

On 5/06/19 8:00 AM, Pavan Kumar wrote:
> Hello Experts,
>
> I have couple of questions on postgres installation.
>
> 1. which way of installation is better ? source code or rpm based ?
> 2. for instance , If we need to install same version postgres on
> multiple times on same server. how do we need to handle this with rpm ?
> 3. If I go with source code installation, in case we need to upgrade
> OS(6 to 7) , do we need to recompile existing postgres binaries ?
>
> kindly share your experience.
>
>

Hi,

Some thoughts on these points:

Re 1: Source based is better if you want to customize compile time
variables (block size etc). However the (substantial) down side of that
approach is you need to be rebuilding for all the point releases (i.e
bug and security updates) as they come out- it is easy to forget or not
bother and end up way behind. This is where the rpm approach shines as
it does this for you.

Re 2: not sure (I use debs not rpms), however typically the install path
for binaries is fixed (i.e so you cannot install the same version in
multiple places). Also I'm not clear why you would want to do this.

Re 3: you might need to recompile in some cases after an upgrade
(dynamic linking to libraries outside the Postgres src that can get
their versions changed to the point where Postgres libs won't load
anymore). However testing should highlight this.

regards

Mark

> On Jun 5, 2019, at 10:23 AM, Pavan Kumar <pavan.dba27@gmail.com> wrote:
>
> 1. Imagine a case where binaries got corrupted. what will happen to the database cluster?
> 2. One of the database had problem and need to apply bug fix patch at binaries. how do we handle this problem?
> 3. minor release

Custom builds sounds like the solution you need. I wouldn’t install the same version multiple times; however, having
twodifferent patch releases makes sense.  For example, install one version of 10.1 and use it for multiple database
clusters. Install version 10.2 in a different directory and update a given database cluster environment to use 10.2
binariesthus allowing for both 10.1 and 10.2 to be running on the same server.   

I don’t think RPMs will allow you to run different patch releases.

P.s.

I have both 10.7 and 11.3 running on the same system without issue.  Normally run one database cluster on the system;
however,currently migrating between major versions and using the system for testing and migration efforts.