Re: [Gnumed-devel] Postgres 8.4.4-1 (Enterprise db) problems -- system hosed?

[Sebastian Hilbert]

Am Donnerstag 01 Juli 2010, 11:30:46 schrieb Jim Busser:
> On 2010-07-01, at 1:38 AM, Karsten Hilbert wrote:
> > On Thu, Jul 01, 2010 at 09:37:03AM +0200, Hilbert, Sebastian wrote:
> >>>   Select the locale to be used by the new database cluster
> >>>   [Default locale]
> >>> 
> >>> ---> I set this to en_CA
> >> 
> >> Set it to C.
> > 
> > C would work (is intended to anyway).
> > 
> > However, if the only selection they let you make is "en_CA"
> > that would mean they are *assuming* an encoding - because
> > they do not specify one (as in .utf-8 etc).
> > 
> > I then wonder *which* they are assuming.
> 
> The installer allows only to select the locale, but not to set the encoding

Stupid bitrock installer. This needs to be reported to edb as a bug. They can 
add that option in their installer and then feed it to initdb. This has long 
been possible in the Windows version for 8.3. But for 8.4 the PG community 
seems to have deviced to kill the msi-based installer in favor of the bitrock 
closed source installer. 

What a mistake. They have killed a number of silent install options along with 
it.

> and furthermore simple Mac users who made a bad choice need to be warned
> that simply running the Enterprisedb binary uninstaller will leave behind
> not only the postgres system user,
> but also /Library/PostgreSQL/8.4/data

This needs to go into our docs. It is industry standard to never touch data 
while uninstalling. You would not want your GNUmed database killed because 
some stupid uninstaller decided to remove the PG server, right ?

> which will retain the postgresql.conf file (which will keep the locale) and
> other files.

Sure and that is the way it is supposed to be. We need to inform the user. 
However this is all well documented all over the internet. Users do not read 
the docs. I get asked what's the password for any-doc at least once a week.
It is mentioned everywhere in the wiki, googe.

> 
> Retaining the files in /data will cause the installer to deny the user the
> option to choose anew the needed locale. Ironically, what is needed is
> simply [Default locale].
> 
> en_CA
>       --> client_encoding = UNICODE (I think)
> 
That would be interesting to find out. I guess it will be whatever PG deems 
default on a platform.

> C
>       --> client_encoding = SQL_ASCII (apparently)
> 
I guess they are thinking to play it safe. This is bad and needs to be 
reported so edb can fix their installer or get rid of it all together.

> [Default locale]
> 
>       --> locale = "C", client_encoding = UTF8 (apparently)

which would indicate they are trying to make some smart choices. this could 
change any time and is by no means safe to rely on.

> 
> I am getting closer... I now got up to v6-v7... attached is the bottom
> portion of the log
> 
> ==> bootstrapping "v6-v7-static" ...
> ==> cloning [gnumed_v6] (19 MB) as target database [gnumed_v7] ...
> ==> transferring users ...
> ==> bootstrapping "v6-v7-dynamic" ...
> ==> setting up auditing ...
>    ... skipped (disabled)
> ==> setting up notifications ...
>    ... skipped (disabled)
> ==> upgrading reference data sets ...
> closing open connection from: database.__connect_owner_to_db via
> database.__connect_superuser_to_db <connection object at 0x101386e00; dsn:
> 'dbname=gnumed_v7 port=5432 user=postgres password=xxxxxxxx
> sslmode=prefer', closed: 0> Bootstrapping failed: unhandled exception
> occurred
> 

Been there :-)

The solution is to copy everything into /tmp and bootstrap from there.