Re: postgres source code installation vs rpm based installation

From: Rui DeSousa <rui(at)crazybean(dot)net>
To: Pavan Kumar <pavan(dot)dba27(at)gmail(dot)com>
Cc: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: postgres source code installation vs rpm based installation
Date: 2019-06-05 14:47:58
Message-ID: 1E7EF29F-3C87-4FC8-8A76-2E37E22C75E6@crazybean.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> On Jun 5, 2019, at 10:23 AM, Pavan Kumar <pavan(dot)dba27(at)gmail(dot)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 two different 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 binaries thus 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.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Pavan Kumar 2019-06-05 14:48:18 configure multiple repository path in pgbackrest
Previous Message Pavan Kumar 2019-06-05 14:23:13 Re: postgres source code installation vs rpm based installation