Re: [GENERAL] Finally upgrading to 9.6! - Mailing list pgsql-general

From Scott Marlowe
Subject Re: [GENERAL] Finally upgrading to 9.6!
Date
Msg-id CAOR=d=3oxJqwyqVi_OVXrPZfLHfhRkgt4eP=gabX1K83=vYo-Q@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Finally upgrading to 9.6!  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-general
On Wed, Oct 18, 2017 at 11:26 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On 10/18/2017 08:49 AM, Ron Johnson wrote:
>>
>> On 10/18/2017 10:16 AM, Igal @ Lucee.org wrote:
>>>
>>> On 10/18/2017 7:45 AM, Ron Johnson wrote:
>>>>
>>>> On 10/18/2017 09:34 AM, Igal @ Lucee.org wrote:
>>>>>
>>>>> A bit off-topic here, but why upgrade to 9.6 when you can upgrade to
>>>>> 10.0?
>>>>
>>>>
>>>> There's no way we're going to put an x.0.0 version into production.
>>>
>>>
>>> Then think of it as 9.7.0 but with an easier name to pronounce ;)
>>
>>
>> No .0 is going into production...
>>
>
> I am not sure why this is even a question. There are plenty of businesses
> that can risk the deployment of a .0 release but there are also *MANY THAT
> CAN NOT*. The proper way to do this is to have a staging server running the
> .0 release that gets beaten on by the application for a few months and
> reports anything back to the community they find.

In a past job I would routinely setup a slony slave running the new
version to check to make sure the new version wouldn't choke on the
data in the master etc, then start using it as a read slave after a
few months to make sure the app got along with it as a read only
source, then finally look at promoting it to master, with the option
to unpromote it should things explode. Minimal downtime for upgrades
AND a path back to the old version quickly if needed.

All while having setup dev and stage servers ahead of time to get
beaten on of course.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

pgsql-general by date:

Previous
From: Vik Fearing
Date:
Subject: Re: [GENERAL] Table partionning : INSERT with inconsistent returnligne inserted.
Next
From: Fabricio Pedroso Jorge
Date:
Subject: [GENERAL] Monitoring Tool for PostgreSQL