[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Development testing on Production (?) servers --

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: Development testing on Production (?) servers -- was 0.3-rc4 released
Date: Tue, 19 Aug 2008 14:05:03 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Aug 19, 2008 at 03:23:37AM +0200, Jerzy Luszawski wrote:

> I see no problem. 
> Create backup (or schema scripts) of current db. (use pgadmin3 or pg_dump)
> Create new db with different name.
> Restore data from backup or generate schema in the new database. (use psql \i 
> command, pgadmin did not work)
> Modify gm-from-cvs.conf adding a profile pointing to the new database.

One also needs to adjust database permissions for users to
be able to connect.

> Note1: When logging in a message pops up, saying '
>  option [lc_messages] = [pl_PL.UTF-8] risks "suboptimal error detection"'
> - maybe I created the db with wrong option, I did not pay attention to it.

That's our client sanity-checking the database it connects
to ...   Since the GNUmed code does not speak Polish (nor
German) it may not be able to properly detect some error
conditions when PostgreSQL utters Polish messages.

> Note2: I completely don't know why, but with database
> gnumed_v9 I can leave 'host = " parameter in
> gm-from-cvs.conf empty, but with new database I must have
> 'host= localhost' to be able to log in. Strange.

First, lets assume the new database is "gnumed_v9_new". Now,
since there is no database users group "gnumed_v9_new" the
"local samegroup ..." line in pg_hba.conf does not apply.

It then likely finds a "host ..." rather than "local ..."
further down in pg_hba.conf which allows it to connect via
tcp/ip rather than local unix domain sockets.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]