[Dbconfig-common-devel] plpgsql_call_handler

H ochominutosdearco at gmail.com
Thu Sep 8 12:58:15 UTC 2005


Ok, now i uninstalled all.

1 Unistall bulmafact-server (i have been forced to uninstall without dbconfig 
becouse the other option ended with error and no dbconfig uninstalled )

2 dbconfig-common  that gives the problem in the directory /etc/dbconfig (if i 
remember well) the only solution was to delete that diretory

3 postgresql-8.0

That did not worked well.

My bigest problem now is that i can not reinstall postgresql-8.0

The shell result of the try to install postgres:

dpkg -l | grep postgr
rc  gda2-postgres                 1.2.1-2                  PostgreSQL backend 
plugin for GNOME Data Acc
rc  postgresql-common             23                       manager for 
PostgreSQL database clusters
gpg4all:/home/h# apt-get install postgresql-8.0
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
Se instalarán los siguientes paquetes extras:
  postgresql-client-8.0 postgresql-common
Paquetes sugeridos:
  postgresql-doc-8.0
Se instalarán los siguientes paquetes NUEVOS:
  postgresql-8.0 postgresql-client-8.0 postgresql-common
0 actualizados, 3 se instalarán, 0 para eliminar y 107 no actualizados.
Se necesita descargar 0B/5234kB de archivos.
Se utilizarán 16,0MB de espacio de disco adicional después de desempaquetar.
¿Desea continuar? [S/n]
Seleccionando el paquete postgresql-common previamente no seleccionado.
(Leyendo la base de datos ...
142767 ficheros y directorios instalados actualmente.)
Desempaquetando postgresql-common (de .../postgresql-common_23_all.deb) ...
Seleccionando el paquete postgresql-client-8.0 previamente no seleccionado.
Desempaquetando postgresql-client-8.0 
(de .../postgresql-client-8.0_8.0.3-7_i386.deb) ...
Seleccionando el paquete postgresql-8.0 previamente no seleccionado.
Desempaquetando postgresql-8.0 (de .../postgresql-8.0_8.0.3-7_i386.deb) ...
Configurando postgresql-common (23) ...
Executing upgrade script test...

Configurando postgresql-client-8.0 (8.0.3-7) ...

Configurando postgresql-8.0 (8.0.3-7) ...
Creating new cluster (configuration: /etc/postgresql/8.0/main, 
data: /var/lib/postgresql/8.0/main)...
FATAL:  XX000: failed to initialize lc_messages to ""
LOCATION:  InitializeGUCOptions, guc.c:2389
el proceso hijo terminó con código de salida 1
initdb: eliminando el contenido del directorio «/var/lib/postgresql/8.0/main»
Error: initdb failed
dpkg: error al procesar postgresql-8.0 (--configure):
 el subproceso post-installation script devolvió el código de salida de error 
1
Se encontraron errores al procesar:
 postgresql-8.0
E: Sub-process /usr/bin/dpkg returned an error code (1)


El Miércoles, 7 de Septiembre de 2005 16:23, Karsten Hilbert escribió:
> In PostgreSQL when you create a database it is templated
> from the pre-existing database "template1".
>
> Template1 is, however, also user-changeable.
>
> So, if someone happened to install something (tables,
> procedural languages) into template1 it is copied into any
> new database upon "create database".
>
> That way it is possible that someone created the function
> "plpgsql_call_handler" in "template1". Then, when creating
> "bulmafactserver" it is copied over to that database.
> Subsequently the install script tries to install the
> procedural language (plpgsql) and fails because the function
> already exists. This is a bug in the "bulmafact-server
> --install" bootstrapper.
>
> > so, it sounds like when you remove the package, the plpgsql stuff isn't
> > removed?  i don't know pgsql very well, but my guess is that we need to
> > provide some way to perform administrative operations before the database
> > is removed.  so right now we have an "install", and "install-dbadmin"
> > directory, maybe we need a "uninstall-dbadmin" directory too, which
> > could be executed as the dbadmin when the admin selects the "purge
> > database" option during removal?
>
> Sounds very useful.
>
> > does that seem right?  or is it already the case that purging the
> > database during package removal will fix this?
>
> It should unless something was created in template1 because
> of which it would come back to life in any newly created
> database.
>
> > > I tried to uninstall the 1.8.4 and try to isntall 1.8.3 but the problem
> > > was not solved, there still remains the same problem.
>
> So the sequence was:
>
> new PostgreSQL
> install with 1.8.3 - success
> install with 1.8.4 - failure
> install with 1.8.3 - failure, too
>
> This supports the theory that something survices purging the
> database inbetween (by means of existing in template1).
>
> This appears to be a bulmafact-server issue.
>
> Karsten

-- 
http://h.says.it
jabber:  h at myjabber.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20050908/69c0cd93/attachment.pgp


More information about the Dbconfig-common-devel mailing list