Categoría: PostgreSQL

Publicado el por — Dejar un comentario

Postgresql 15: permission denied for schema public

Un cliente desarrolla aplicaciones web con Django y al hacer el deploy de su aplicación y crear las tablas en la base de datos Postgresql versión 15 (migrations) le lanzaba el siguiente error:

“… (permission denied for schema public LINE 1: CREATE TABLE ….”

Al usuario de conexión a la base de datos se le habían asignado todos los permisos o privilegios sobre la base de datos que regularmente el cliente asignaba en anteriores instalaciones con éxito donde la instalación había funcionado sin problemas.

La diferencia con las instalaciones anteriores era la versión del Postgresql, lo había hecho en versiones 14 o anteriores de este motor de base de datos. Revisando la documentación de la versión 15 se encontró que el permiso de creación en al esquema PUBLIC ya no es público por lo que hay que darle el permiso explícito al usuario. Sólo el propietario de la base de datos tiene por defecto el permiso de creación en el esquema PUBLIC. El cliente había creado la base de datos con el usuario administrador postgres, por lo tanto el propietario por defecto era el usuario postgres. Una solución para corregir este error es hacer, al usuario de conexión, el propietario de la base de datos ejecutando el siguiente comando SQL:

ALTER DATABASE <nombre-base-de-datos> OWNER TO <usuario>;

Una vez ejecutado el comando, la aplicación se instaló sin problemas.

¡Hasta pronto!

Publicado el por — Dejar un comentario

SQL: regresar un valor en lugar de nulo (null) en una consulta.

En ocasiones una consulta SQL puede regresar en una de sus columnas un valor nulo, pero necesitamos que en su lugar regrese un valor por defecto ya sea porque necesitamos hacer alguna operación con ese valor o simplemente por estética.

Existen varias funciones que hacen lo mismo según la base de datos de que se trate. Aquí se verá la función COALESCE(). Esta función regresa el primer argumento no nulo de la lista de argumentos que se le pasen. Su sintaxis es:

COALESCE(argumento1, argumento2,…argumentoN)

A ésta función se le deben pasar al menos 2 argumentos. Si todos los argumentos de la lista son nulos, esta función regresara nulo (nul). Los argumentos no nulos dados deben ser del mismo tipo de dato, si no la función podría marcar error. Es decir, deben ser todos numéricos o todos cadena o de otro tipo. Veamos unos ejemplos:

SELECT COALESCE(null, 1, 3) as campo1;

Al ejecutar la sentencia sql anterior, la expresión campo1 regresará el valor 1, ya que es el primer argumento no nulo en la lista de argumentos que se le dió. El ejemplo anterior podrá funcionar en SQLite, SQL Server o Postgresql. En Oracle se debe ejecutar la siguiente sentencia:

SELECT COALESCE(null, 1, 3) as campo1 from dual;

Espero y les sea de utilidad. ¿Dudas u observaciones? Deja tu comentario. ¡Saludos!

Publicado el por — Dejar un comentario

Servicio Postgresql en mantenimiento en Solaris 10

postgresql en mantenimiento

De pronto el servidor de reportes de Pentaho versión 5.4 dejó de funcionar, la aplicación no era cargada por Tomcat y su archivo log mostraba lo siguiente:

SEVERE: The web application [/pentaho] created a ThreadLocal with key of type [java.lang.InheritableThreadLocal] (value [java.lang.InheritableThreadLocal@4bace654]) and a value of type [org.springframework.security.providers.UsernamePasswordAuthenticationToken] (value [org.springframework.security.providers.UsernamePasswordAuthenticationToken@fc3ceceb: Principal: org.springframework.security.userdetails.User@0: Username: admin; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: Admin; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: Admin]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

Al parecer la base de datos Postgresql no estaba funcionando. Al ejecutar el comando siguiente con privilegios de root
svcs postgresql
para saber el estado del servicio regresaba lo siguiente:
bash-3.2# svcs -p postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
maintenance Dec_04 svc:/application/database/postgresql:version_94

La versión 9.4 de Postgresql estaba en estado de mantenimiento (maintenance), al parecer, debido a un corte de energía, la base de datos no se apagó por completo.

Se revisa por qué motivo el servicio quedó en mantenimiento ejecutando:

bash-3.2# svcs -x postgresql
svc:/application/database/postgresql:version_94 (PostgreSQL RDBMS)
State: maintenance since Fri Dec 04 16:52:05 2020
Reason: Method failed.
See: http://sun.com/msg/SMF-8000-8Q
See: postgres_94(5)
See: /var/svc/log/application-database-postgresql:version_94.log
Impact: This service is not running.

Revisamos el archivo log que indica el el comando anterior y la última línea mostraba lo siguiente:

[ Dec 4 16:51:04 Executing stop method (“/lib/svc/method/postgresql stop”) ]
waiting for server to shut down………………………………………………………[ Dec 4 16:52:05 Method or service exit timed out. Killing contract 1187 ]

Al parecer no se completo correctamente el apagado de la Base de Datos.

Así que se revisó si algún proceso del servicio aún había quedado corriendo con el comando:

bash-3.2# svcs -p postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
maintenance Dec_04 svc:/application/database/postgresql:version_94

Lo que mostró que no había otros procesos del servicio postgresql 9.4 corriendo. Si los hubiera habido, hubiera sido necesarios “matarlos” con el comando kill.

Y por último, para activar o poner nuevamente en línea el servicio de Postgresql se corre el comando:

bash-3.2# svcadm clear svc:/application/database/postgresql:version_94

Corremos nuevamente el comando svcs para verificar que el servicio está corriendo de nuevo:

-bash-3.2$ svcs postgresql
STATE STIME FMRI
disabled Sep_26 svc:/application/database/postgresql:version_81
disabled Sep_26 svc:/application/database/postgresql:version_82
disabled Sep_26 svc:/application/database/postgresql:version_82_64bit
online 18:16:25 svc:/application/database/postgresql:version_94

Efectivamente, el servicio está de nuevo en línea. Iniciamos nuestro servidor de reportes de Pentaho y listo, el error se fue.

¡Espero y les sirva! ¡Hasta la próxima!