Re: [Gnumed-bugs] [Gnumed-devel] database version requirement switch: 9.1, was: Problem in git bootstrapping v18 to v19 db

[Busser, Jim]

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