Re: Upgrading from 9.1.2 to 9.1.5

Another question, when I get a reply from the list, to which email
should I then reply?
To all? the User posting, or pgsql-admin(at)?
thanks

On Mon, Sep 10, 2012 at 12:06 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Craig James <cjames(at)emolecules(dot)com> wrote:
>> Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> wrote:
>>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>> On Thu, Sep 6, 2012 at 05:55:05PM -0500, Antoine Guidi wrote:
>>>>> Is it possible to do a pg_upgrade from 9.1.2 to 9.1.5 just
>>>>> using pg_upgrade? For what I could read, the only exception
>>>>> would be if I was using a citext column (which I am not).
>>>>
>>>> You cannot use pg_upgrade for this.
>
> "Cannot" or "don't need to"?
>
>>>> You just need to stop the server, install the binaries, and
>>>> restart the server.
>>>
>>> AFAIU it is not necessary to stop the server when updating
>>> binaries if one is not going to create extensions, PLs or
>>> anything else that will be dynamically linked after the binaries
>>> update and before the server restart.
>>>
>>> So with the process
>>>
>>> 1. update binaries
>>> 2. postgres restart
>>>
>>> the downtime will be shorter.
>>
>> I'm just guessing, but this is probably a bad idea. This could
>> happen...
>>
>> 1. Postgres master and a bunch of clients are running
>>
>> 2. You start updating binaries
>>
>> 3. In the middle of your update, an new client connects and a new
>> backend process starts.
>>
>> 4. The 9.1.2 executable links to the 9.1.5 binaries. Or a 9.1.5
>> executable links to the 9.1.2 libraries. Or a 9.1.5 executable
>> starts with the right binaries, but is talking to a 9.1.2
>> postmaster process, which might not have the same shared-memory
>> map. Or ...
>>
>> ... and so forth.
>
> That's why we put each minor release into a separate location.
>
> 1. PostgreSQL master and a bunch of clients are running against
> executables deployed with a prefix of /usr/local/pgsql-9.1.4. The
> prefix is specified in the service script for the server; clients
> use a symlink at /usr/local/pgsql.
>
> 2. We make and install a new build with prefix
> /usr/local/pgsql-9.1.5.
>
> 3. We change the symlink to point to the new build.
>
> 4. We change the appropriate service script(s) to point to the new
> prefix.
>
> 5. We stop and then start the server(s). (We don't use pg_ctl
> restart because that seems to stay on the same prefix.)
>
> 6. Later, when we confirm that nothing is still referencing the old
> prefix, we remove its subdirectory.
>
> PostgreSQL is down only for the time it takes for a restart. We
> normally do this during off-hours; but even if this is done during
> normal operations, properly coded clients (which retry a database
> transaction if it fails with a broken connection, without giving the
> client any error) only see a short stutter in response time.
>
> -Kevin
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin