[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4.
From: |
Busser, Jim |
Subject: |
Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4. |
Date: |
Sun, 17 Nov 2013 02:32:43 +0000 |
On 2013-11-15, at 6:03 AM, Sebastian Hilbert <address@hidden> wrote:
> Am Freitag, 15. November 2013, 14:29:40 schrieb Karsten Hilbert:
>> On Fri, Nov 15, 2013 at 04:27:05PM +0530, Vaibhav Banait wrote:
>>> - version 8.4. Inside database gnumed_v18 and v19 are seen. I can not
>>> varify whether v19 is complete and errorfree, but gnumed client 1.4 fails
>>> to connect saying schema related problem.
>>
>> It might be possible to bootstrap a v19 within a 8.4, I am not
>> sure about that. It might be that 9.1 is only required for
>> *using* the database.
>>
>
> That is what I think as well.
I have just tested this, using a machine that has only 8.4.
What the shell reports is
==> bootstrapping "v18_fixups-pre_v19" ...
I need the password for the database user [postgres].
Please type the password:
==> cloning [gnumed_v18] (716 MB) as target database [gnumed_v19] ...
==> transferring users ...
==> bootstrapping "v18-v19-static" ...
==> bootstrapping "v18-v19-dynamic" ...
Cannot bootstrap bundles.
Please check the log file for details:
/Users/djb/Downloads/gnumed-server.19.0/server/bootstrap/update_db-v18_v19.log
with the result being an incompletely-bootstrapped v19. It appears the
bootstrapper presently permits
bootstrapping bundle [v18_fixups-pre_v19]
to proceed as far as creating v19 even before it tests the state of minimum
postgres after which the bootstrapper continues, and
accepts 8.4 for [option [bundle v18_fixups-pre_v19 with
"… this is fine with me"
accepts 8.4 for option [bundle v18-v19-static … with
"… this is fine with me"
but it
rejects 8.4 for option [bundle v18-v19-dynamic with
Reported live PostgreSQL version [8.4] is smaller than the
required minimum version [9.1].
…
Wrong PostgreSQL version.
...
Cannot bootstrap bundles.
…
shutdown
resulting in the persistence of an incompletely-bootstrapped v19, demonstrable
from the shell with
psql -d gnumed_v18 -U gm-dbo -c "\l"
and returning a list of databases which include gnumed_v19.
Ideally, the test for minimum postgres would appear prior to the creation of
the new vNN.
The alternative would be to drop the v19 as part of the exit procedure, except
this might be dangerous if accidentally incorporated into a fixup script (not
that it would… I am just being cautious).
-- Jim
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4.,, Vaibhav Banait, 2013/11/15
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4.,, Karsten Hilbert, 2013/11/15
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4.,, Sebastian Hilbert, 2013/11/15
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4.,
Busser, Jim <=
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4., Sebastian Hilbert, 2013/11/17
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4., Sebastian Hilbert, 2013/11/17
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4., Sebastian Hilbert, 2013/11/18
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4., Karsten Hilbert, 2013/11/19
- Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4., Karsten Hilbert, 2013/11/19
Re: [Gnumed-devel] Upgrade from gnumed v1.3.7 to 1.4.,, Karsten Hilbert, 2013/11/15