[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.
From: |
Busser, Jim |
Subject: |
Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db |
Date: |
Wed, 17 Jul 2013 21:18:20 +0000 |
On 2013-07-17, at 2:59 AM, Karsten Hilbert <address@hidden> wrote:
> On Tue, Jul 16, 2013 at 12:11:10AM +0000, Jim Busser wrote:
>
>>> I have pushed this whole shebang of coding frenzy into the
>>> public repository. It should be stress-tested for bugs.
>>
>> Does the v18 --> v19 db upgrade SQL have a bug?
>>
>> I can't run it successfully to completion.
>
> OK, so it seems older PG versions did not have
> pg_constraint.convalidated. This column tells us whether a
> given constraint is fully active on all rows of a given
> table. This protects patient data against someone dropping a
> constraint, inserting a bunch of invalidly linked data, and
> recreating the constraint as NOT VALID (and thusly, inactive
> on the existing, invalid rows).
>
> Further examination shows that this has been introduced with
> PG 9.1 which has been released in September 2011. Debian
> Stable contains 9.1, too.
>
> I should think this is the time to switch and require PG 9.1.
>
> This will finally enable all sorts of nifty things to happen
> such as a much improved database notification listener
> (which should help with speed and some concurrency issues
> resulting in hangs or crashes when accessing the EMR of a
> patient).
>
> So, I guess 1.4 will require PG 9.1.
1. If at http://www.enterprisedb.com/products-services-training/pgdownload
9.2 is available
is there a preference that users *not* use 9.2, or does it likely not matter?
2. As far as the upgrade path from 8.4, maybe the EnterpriseDB one click
installer takes care of everything at
http://www.postgresql.org/docs/9.2/static/pgupgrade.html
except if it may stops short of applying pg_upgrade (whether by choice or by
some problem to do with 64 vs 32 bit-ness as described at
http://www.postgresql.org/message-id/address@hidden) ...
However is my safety net to ensure that I have backed up my
backup-gnumed_v18-GNUmed_Team-MacBook-2.local-2013-07-17-13-48-15-database.sql
backup-gnumed_v18-GNUmed_Team-MacBook-2.local-2013-07-17-13-48-15-roles.sql
and if I should migrate to a VM are these .sql files my means to import my data
into a new pg?
-- Jim
- [Gnumed-bugs] Problem in git bootstrapping v18 to v19 db, Busser, Jim, 2013/07/15
- Re: [Gnumed-bugs] Problem in git bootstrapping v18 to v19 db, Karsten Hilbert, 2013/07/16
- [Gnumed-bugs] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db, Karsten Hilbert, 2013/07/17
- Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db,
Busser, Jim <=
- Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db, Karsten Hilbert, 2013/07/17
- Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db, Busser, Jim, 2013/07/17
- Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db, Karsten Hilbert, 2013/07/18
- Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db, Busser, Jim, 2013/07/18
- Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db, Karsten Hilbert, 2013/07/18