1. Curso de administracion de PostgreSQL
INCOP - Marzo 2010
Jaime Alberto Casanova Merchán
Email: jcasanov@systemguards.com.ec

2. Índice de contenido
Conceptos básicos y estructura interna.................................................................................................4
El proceso Postmaster .....................................................................................................................4
La memoria compartida ..................................................................................................................4
WAL: Write-Ahead Log ..................................................................................................................4
¿Qué es? .....................................................................................................................................4
WAL: Principios de diseño ........................................................................................................5
¿Qué es un registro de WAL?......................................................................................................5
Consideraciones sobre el WAL ..................................................................................................5
Checkpoints ................................................................................................................................5
Estructura del WAL ....................................................................................................................6
Nombres de los archivos del WAL .............................................................................................6
Detectando el final del WAL ......................................................................................................6
MVCC: Multi Version Concurrency Control ..................................................................................7
¿Qué es? .....................................................................................................................................7
Beneficios de MVCC .................................................................................................................7
Implementación ..........................................................................................................................7
Consideraciones sobre MVCC....................................................................................................9
Tareas de mantenimiento ..............................................................................................................10
VACUUM.................................................................................................................................10
VACUUM FULL ......................................................................................................................10
Alternativas a VACUUM FULL ..............................................................................................10
CLUSTER ...........................................................................................................................11
ALTER TABLE / SET TYPE ..............................................................................................11
ANALYZE................................................................................................................................11
REINDEX ................................................................................................................................11
Autovacuum .............................................................................................................................11
Concepto de “Cluster de bases de datos” en PostgreSQL.............................................................12
Jerarquía de Objetos a nivel lógico...........................................................................................12
Instalando PostgreSQL ......................................................................................................................14
Instalando desde los fuentes..........................................................................................................14
Requisitos .................................................................................................................................14
Procedimiento de instalación....................................................................................................14
Crear el usuario postgres......................................................................................................15
./configure.............................................................................................................................15
make ....................................................................................................................................15
make install...........................................................................................................................15
initdb.....................................................................................................................................16
Instalación desde repositorios........................................................................................................16
Procedimiento instalación.........................................................................................................16
Instalación desde el instalador.......................................................................................................17
Procedimiento instalación.........................................................................................................17
Actualización.................................................................................................................................17
Versiones menores.....................................................................................................................17
Versiones mayores.....................................................................................................................17
Estructura física.............................................................................................................................17
Archivos ...................................................................................................................................18
Directorios.................................................................................................................................18
-2-

3. Aplicaciones instaladas..................................................................................................................19
Aplicaciones cliente..................................................................................................................19
Aplicaciones servidor................................................................................................................19
Módulos adicionales.................................................................................................................19
Si instalamos desde los fuentes............................................................................................20
Si instalamos desde los repositorios ....................................................................................20
Si instalamos desde el instalador .........................................................................................20
Configuración del Servidor................................................................................................................21
Párametros del Kernel....................................................................................................................21
Consideraciones sobre el Sistema de Discos.................................................................................21
Archivos de configuración de PostgreSQL...................................................................................21
postgresql.conf..........................................................................................................................21
Ubicación de ficheros ..........................................................................................................21
Conexión .............................................................................................................................21
Seguridad y autenticado ......................................................................................................22
TCP Keepalives....................................................................................................................22
Uso de recursos : Memoria ..................................................................................................22
Uso de recursos del kernel ...................................................................................................23
Retraso del vacuum basado en costo....................................................................................23
Configuración del proceso bgwriter.....................................................................................23
Comportamiento asincrónico...............................................................................................23
Write Ahead Log..................................................................................................................23
Checkpoints .........................................................................................................................24
Archivado del WAL..............................................................................................................24
Método de planificación y optimización .............................................................................25
Constantes de costeo para la planeación..............................................................................25
GEQO (Genetic Query Optimizer) ......................................................................................25
Otras opciones para la planeación........................................................................................26
Configuración del log...........................................................................................................26
Estadísticas ..........................................................................................................................28
Autovacuum ........................................................................................................................28
Predeterminados para las conexiones cliente ......................................................................29
Localización y formato ........................................................................................................29
Gestión de Bloqueos ............................................................................................................29
Compatibilidad con versiones anteriores de PostgreSQL....................................................30
Compatibilidad con otras plataformas y clientes.................................................................30
Opciones especiales..............................................................................................................30
pg_hba.conf...............................................................................................................................30
-3-

4. Conceptos básicos y estructura interna
El proceso Postmaster
• es el proceso inicial
• gestiona los accesos multiusuario y multiconexión
• levanta la memoria compartida
• está al tanto de solicitudes de nuevas conexiones
• lanza procesos de atención de demanda, realizando las operaciones sobre la base de datos a
solicitud de los clientes
• realiza el enlazado con los archivos de datos, gestionando estos ficheros, donde los ficheros
pueden pertenecer a varias bases de datos
La comunicación entre BackEnd/FrontEnd se realiza mediante TCP/IP, normalmente por el puerto
5432, creando un socket (/tmp/.s.PGSQL.5432).
La memoria compartida
• gestiona los recursos entre procesos backend
• gestiona la caché del disco
• maneja otras estructuras internas
De esta manera podemos definir el concepto de CLUSTER DE BASE DE DATOS, como una
instancia de PostgreSQL, donde se lanza un proceso postmaster, que puede gestionar varias bases
de datos. En un servidor, pueden haber varios cluster, cada uno tendrá su postmaster, y cada
postmaster escuchará por un puerto diferente.
No confundir este concepto de “cluster” con los típicos que se manejan en bases de datos de
“base de datos en cluster” o “tablas en cluster”.
WAL: Write-Ahead Log
¿Qué es?
Siglas: Write
Ahead
Log
Es un log de escritura adelantada, también conocido como log transaccional o REDO log por otros
gestores de bases de datos; en el que se graban todos los cambios efectuados a las páginas de datos
antes de efectuar tales cambios. Puesto que solo este log es necesario para garantizar que los
cambios permaneceran aun en el caso de caída del servidor también se reduce la cantidad de
escrituras a disco aumentando así el rendimiento.
El WAL es la base para lograr respaldos incrementales, recuperación hasta un punto en el tiempo
(PITR) y una técnica de alta disponibilidad conocida como Warm Standby.
-4-

5. WAL: Principios de diseño
El log de transacciones consiste en una serie de registros de log los cuales describen los cambios
que se están realizando a la base de datos y por lo tanto debe existir un registro de log por cada
cambio realizado.
El registro en el WAL de una operación siempre se escribe primero que las páginas de los datos
afectados, esto asegurá que los cambios permanecerán aun cuando el servidor por algún motivo
dejará de funcionar abruptamente.
En caso de que el servidor tenga una caída, se reconstruyen las transacciones comprometidas
(aquellas en las que se ha hecho COMMIT), y que aún no se hayan escrito en las páginas de los
datos, leyendo desde el WAL
¿Qué es un registro de WAL?
Lleva los detalles de la operación a realizar (ej: que tipo de operación es, en que base de datos, en
que tabla o índice en que página de disco, información de estado del snapshot de la transacción, la
posición del registro de WAL anterior, etc...).
Ejemplo:
INSERT INTO foo VALUES (1234, ’foobar’);
insert: ts 1663 db 11564 rel 16389 block 0 off 2
header: t_infomask2 2 t_infomask 2050 t_hoff 24
0/004F8E14: prv 0/004F8DD0; xid 655; BTREE info 00 len 30 tot_len 58
insert_leaf: index 1663/11564/16395 tid 1/1
0/004F8E50: prv 0/004F8E14; xid 655; XACT info 00 len 24 tot_len 52
commit: 655 at 1979-10-31 18:02:49 EET
Consideraciones sobre el WAL
Si está en el WAL está seguro, es decir que podrá recuperarse de una caída del servidor sin perdida
de datos...
• a menos que se dañe el disco
• o que no vaya al disco en el orden correcto, en este caso habrá corrupción de datos.
◦ Esto último puede ocurrir si hemos desactivado el parámetro fsync en el postgresql.conf
◦ O si tenemos activo el cache de escritura en el disco (entonces el disco decidirá cuando
grabar cada cosa y puede no ser el orden que esperabamos).
Cosas que no van al WAL
• tablas temporales
• índices hash, para recuperar un índice hash despues de una caída de servidor es necesario
usar el comando REINDEX.
Se escribe en disco dos veces: primero al WAL y luego a las páginas de datos, aunque no al mismo
tiempo; por eso es recomendable poner el directorio del WAL en otro disco.
El WAL no se puede apagar, y aunque se pudiera no sería deseable hacer tal cosa pues se perdería
la habilidad de recuperarse de caídas del servidor.
Checkpoints
El WAL crea tantos archivos como necesite, por eso a menos que se reutilicen los archivos viejos
podría crecer indefinidamente .
-5-

6. Para evitar que lleguen a ocupar demasiado espacio en disco están los checkpoints que se encargan
de sincronizar los cambios registrados en el WAL a las páginas de disco de las tablas e índices.
Un checkpoint realiza las siguientes operaciones:
1. Sincroniza todos los cambios en las páginas de datos al disco
2. Escribe en WAL un registro de checkpoint
3. Borra los WAL viejos
Un checkpoint en modo de recuperación, es decir el que se ejecuta al inciar el servidor, realiza lo
siguiente:
1. Determina el punto de inicio de recuperación en el WAL es decir, qué transacciones que
están comprometidas aún no se han sincronizado a las páginas de los datos
◦ pg_control
2. Sincroniza todos los cambios en las páginas de datos al disco
3. Escribe en WAL un registro de checkpoint
4. Borra los WAL viejos
Estructura del WAL
El WAL esta dividido en segmentos. Cada segmento es un archivo en el directorio
$PGDATA/pg_xlog, generalmente de 16MB cada uno (configurable en tiempo de compilación).
$ ls -l
total 131236
-rw------- 1 postgres postgres 16777216 nov 18 21:09 000000010000000000000041
-rw------- 1 postgres postgres 16777216 nov 9 17:12 000000010000000000000042
-rw------- 1 postgres postgres 16777216 nov 9 17:12 000000010000000000000043
-rw------- 1 postgres postgres 16777216 nov 9 17:12 000000010000000000000044
-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000045
-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000046
-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000047
-rw------- 1 postgres postgres 16777216 nov 9 17:13 000000010000000000000048
drwx--S--- 2 postgres postgres 4096 nov 9 17:08 archive_status
Nombres de los archivos del WAL
El nombre de los segmentos del WAL consta de 3 partes :
Usemos el siguiente nombre de un segmento de WAL para nuestro ejemplo:
000000010000000000000048
1. Los primeros 8 dígitos (contando de izquierda a derecha), indican el id de la línea de tiempo
del registro.
◦ El id de la linea de tiempo se usa para distinguir segmentos de WAL generados antes y
despues de una recuperacion PITR.
2. Los siguientes 8 dígitos (contando de izquierda a derecha), indican el id del log
3. Los ultimos 8 dígitos (contando de izquierda a derecha), indican el id (secuencial) del
segmento
Los últimos 16 dígitos en conjunto conforman la primera parte del LSN .
Detectando el final del WAL
¿Como se determina donde termina el WAL, de forma que no se intente sincronizar basura? Cada
registro tiene un puntero que apunta al registro anterior en la cadena si no coinciden, hemos llegado
al final del WAL
-6-

7. MVCC: Multi Version Concurrency Control
¿Qué es?
Siglas: Multi
Version
Concurrency
Control
Es una técnica para el control de acceso simultáneo (concurrencia) a traves de la gestión de
múltiples versiones de un mismo registro (tuplas).
Mediante el uso de MVCC, PostgreSQL evita el problema de que procesos lectores estén esperando
a que se termine de escribir. En su lugar, PostgreSQL mantiene una ruta a todas las transacciones
realizadas por los usuarios de la base de datos. PostgreSQL es capaz entonces de manejar los
registros sin necesidad de que los usuarios tengan que esperar a que los registros estén disponibles.
La idea básica es evitar al máximo los bloqueos, así usando MVCC logramos que:
• Una lectura no bloquee a otra lectura
• Una escritura no bloquee a una lectura
• Una escritura no bloquee a otra escritura
◦ a menos que deban escribir el mismo registro
Beneficios de MVCC
• Flexibilizar el acceso a los datos gracias a los candados ligeros , postgres siempre toma
algún tipo de bloqueo pero siempre es el mínimo necesario.
• Facilita la vida de los desarrolladores puesto que se reduce la necesidad de gestionar
manualmente los bloqueos.
• Permite tener niveles de “aislamiento” en la transacción, esto es que cada transacción ve
datos de manera independiente y por lo tanto no es posible ver datos inconsistentes debido a
cambios realizados por una transacción no finalizada.
Implementación
• Cada transacción que escribe datos en una tabla, tiene un identificador de transacción (xid)
• Cada registro de las tabla contiene dos informaciones esenciales:
◦ Identificador de transacción (xid) que creó el registro (XMIN)
◦ Identificador de transacción (xid) que destruyó el registro (XMAX)
• Cada proceso “ve” una imagen (snapshot) específica de la base de datos, esa imagen es
guiada por los siguientes principios:
◦ ve las tuplas (una versión de un registro) cuyo identificador de creación sea inferior al
identificador de la transacción del proceso
◦ y cuyo identificador de destrucción sea mayor al identificador de la transacción del
proceso
◦ y evidentemente, a condición de que la transacción de creación y destrucción de la tupla
sean válidas
◦ además debe comparar los identificadores de creación y destrucción con el conjunto de
identificadores de transacción de otros procesos que estaban en curso al momento de
iniciar la transacción
-7-

8. Veamos un ejemplo:
-- creamos una tabla
CREATE TABLE t1 (
i integer,
t text
);
-- Insertamos algunos registros, 3 para empezar
INSERT INTO t1 VALUES (1, ’uno’), (2, ’dos’), (3, ’tres’);
-- Verificamos su existencia con un SELECT
SELECT * FROM t1;
i t
1 uno
2 dos
3 tres
(3 filas)
De forma automática se insertan además unos campos especiales en todos los registros, estos
campos no son visibles normalmente a menos que pidamos que nos los muestre; por ejemplo:
• xmin: Identificador de la transacción que creó el registro
• xmax: Identificador de la transacción que destruyó el registro
• ctid: Posición física del registro en la tabla
SELECT xmin, xmax, ctid, * FROM t1
xmin xmax ctid i t
1078 0 (0,1) 1 uno
1078 0 (0,2) 2 dos
1078 0 (0,3) 3 tres
(3 filas)
Actualicemos un registro :
UPDATE t1 SET t = upper(t) WHERE i = 2;
SELECT xmin, xmax, ctid, * FROM t1
xmin xmax ctid i t
1078 0 (0,1) 1 uno
1078 0 (0,3) 3 tres
1079 0 (0,4) 2 DOS
(3 filas)
¿Qué ha pasado?
• La línea de ctid (0,2) está “muerta” y por lo tanto no es visible cuando ejecutamos el
SELECT
• La nueva versión está en ctid (0,4)
Volvamos a actualizar
UPDATE t1 SET t = upper(t) WHERE i = 2;
SELECT xmin, xmax, ctid, * FROM t1
-8-

9. xmin xmax ctid i t
1078 0 (0,1) 1 uno
1078 0 (0,3) 3 tres
1080 0 (0,5) 2 DOS
(3 filas)
• PostgreSQL crea una nueva copia del registro aun cuando la actualización no causo ningún
cambio visible
◦ Tenemos una tupla viva distinta
◦ Tenemos una nueva tupla muerta
¿Y si insertamos un nuevo registro?
INSERT INTO t1 VALUES (4, ’cuatro’);
¿En qué posición lo guardará?
En la posición 2?
En la posición 4?
En la posición 6?
xmin xmax ctid i t
1078 0 (0,1) 1 uno
1078 0 (0,3) 3 tres
1080 0 (0,5) 2 DOS
1081 0 (0,6) 4 cuatro
(4 filas)
Consideraciones sobre MVCC
Las actualizaciones en una tabla dejan registros muertos que abultan la tabla y causan
fragmentación
• el problema es cuando esa fragmentación obliga a crear nuevas páginas en disco, si la
fragmentación ocurre dentro de una misma páginas es manejable
◦ para lograr que la fragmentación ocurra dentro de la misma página podemos usar la
cláusula FILLFACTOR (por omisión: 100% para tablas y 90% para índices)
• porque causa que las lecturas secuenciales se vuelvan más lentas
◦ De ahí la pérdida de rendimiento
El espacio muerto no se reutiliza de forma automática.
• Para recuperar el espacio muerto de una tabla es necesario ejecutar la orden VACUUM
◦ VACUUM lee secuencialmente toda la tabla
▪ a partir de la versión 8.4 sólo lee aquellas páginas que fueron modificadas desde la
última vez que se ejecutó VACUUM
▪ VACUUM completo es obligatorio si la tabla excede de vacuum_freeze_table_age
◦ Verifica para cada registro, si aún está vivo para alguna transacción en curso
▪ Si no lo está, compacta el espacio y registra el espacio libre de la página en una
estructura llamada FSM (Free Space Map o “Mapa de espacio libre”)
Para versiones anteriores a 8.4:
El FSM era una estructura en memoria compartida de tamaño fijo y controlada por los parámetros:
• max_fsm_relations
-9-

10. • max_fsm_pages
De 8.4 en adelante:
El FSM es una estructura en disco que puede crecer automáticamente para ajustarse a la tabla y ya
no necesita administración manual a través de los parámetros max_fsm_*
Al ejecutar VACUUM el tamaño de la tabla no cambia o lo hace muy poco; para realmente reducir
el tamaño al mínimo debe usarse VACUUM FULL .
Aún así no se recomienda el uso de VACUUM FULL por que bloquea cualquier operación sobre la
tabla (incluso lecturas) y degrada el rendimiento de los índices .
Sin embargo, es útil en algunos casos ; por ejemplo cuando hay muchos registros borrados de golpe
o cuando uno ha estado usando la BD mucho tiempo con el FSM mal configurado .
MVCC tiene muchas ventajas al permitir la mejor concurrencia posible sin causar conflictos, pero
tambien tiene inconvenientes que pueden ser disminuidos mediante el correcto uso de:
• VACUUM
• FILLFACTOR para controlar la fragmentación
• y algunos algoritmos internos de reutilización de espacio como: HOT (Heap Only Tuples)
Tareas de mantenimiento
Es posible mejorar el rendimiento de las tareas de mantenimiento aumentando el valor de
maintenance_work_mem
VACUUM
• Se encarga de:
◦ Eliminar registros obsoletos
◦ Compactar el espacio disponible
◦ Registrar cuánto espacio libre hay en esa página en el FSM
◦ Lleva en memoria las direcciones de las tuplas que se eliminaron
◦ Recorrer todos y cada uno de los índices de la tabla para eliminar entradas que hubieran
estado apuntando a registros muertos
• No requiere bloquear la tabla por lo que operaciones de escritura podrían ocurrir
concurrentemente
VACUUM FULL
• Forma más antigua de VACUUM
• No deja ningún espacio libre en las páginas
• Operación posterior necesita extender la tabla
• Desventajas
◦ Requiere bloquear totalmente la tabla
◦ los índices quedan en mal estado
◦ es muy lento
Alternativas a VACUUM FULL
Veamos dos alternativas viables a VACUUM FULL, ambos requieren candados exclusivos igual
-10-

11. que VACUUM FULL pero son más rápidos .
CLUSTER
• Reordena una tabla según un índice especificado
• Reescribe toda la tabla y todos sus índices
• Elimina todo el espacio muerto
• Desventaja: es muy lento si los datos no están ordenados por el índice
ALTER TABLE / SET TYPE
• Esta sentencia cambia el tipo de dato de una columna, pero si específicamos que cambie al
mismo tipo de dato que ya tenía la columna en ese caso funcionará igual que CLUSTER
pero no reordena rá la tabla
ANALYZE
• PostgreSQL tiene un optimizador de consultas basado en costo; de modo que para cada
consulta se busca el mecanismo de ejecución más eficiente, es decir el que “cueste” menos.
◦ El costo total de cada posible plan de ejecución se estima usando ecuaciones de costo y
estadísticas recolectadas de los datos presentes en las tablas
◦ Las estadísticas se obtienen usando el comando ANALYZE
◦ A veces usado como opción en VACUUM . Ej: VACUUM ANALYZE
• Si las estadísticas no están ajustadas a la realidad, pueden pasar cosas raras
• Sobre todo, que los planes de ejecución sean subóptimos (consultas lentas)
REINDEX
• Reescribe los índices de una tabla
• Útil cuando los índices se salen de manos
• No debería usarse con periodicidad
◦ sólo para casos patológicos
Autovacuum
Con el objetivo de lograr un sistema libre de administración es posible automatizar VACUUM y
ANALIZE (que son las tareas mas importantes y deberían ejecutarse periodicamente), para esto
existe un proceso llamado: Autovacuum (desde la versión 8.1 este proceso esta integrado en la base
de datos, antes de eso se lo podía encontrar como un modulo adicional).
• Desde la versión 8.1 es un daemon manejado internamente por el postmaster y configurable
desde el archivo postgresql.conf
• Es importante configurarlo adecuadamente para que entre en acción a tiempo
◦ a partir de la versión 8.3 hay múltiples trabajos autovacuum concurrentes
• Nunca ejecuta tareas bloqueantes
◦ y si lo hiciera desde la versión 8.3: se suicida para prevenir bloqueos
También es posible configurar el autovacuum por tablas, esto es útil cuando tenemos tablas muy
grandes o con mucho tráfico:
en las versiones 8.1 hasta 8.3, se lo logra usando el catalogo de sistema pg_autovacuum. Ej:
-11-

12. INSERT INTO pg_autovacuum VALUES (’nombre_tabla’::regclass, ’f’, -1, -1, -1, ...);
• los -1 indican que se usará el valor por omisión.
• ¡no usar 0!
Desde la versión 8.4, se usa una sentencia ALTER TABLE. Ej:
ALTER TABLE ...
SET (autovacuum_enable = false, autovacuum_vacuum_scale_factor = 0.05);
Concepto de “Cluster de bases de datos” en PostgreSQL
Repositorio que engloba un conjunto de bases de datos, que contienen objetos que se pueden
guardar en distintos tablespaces y un conjunto de usuarios que se conectan al cluster.
• Una base de datos engloba un conjunto de esquemas, los cuales tienen un usuario
propietario.
◦ En los esquemas es donde se crean los objetos (tablas, índices, procedimientos, vistas,
etc.)
Con lo que tenemos aquí los elementos principales a nivel lógico en un cluster:
• Bases de datos: agrupaciones de esquemas. Por defecto, siempre hay tres bases de datos
creadas, template0, template1 y postgres.
• Esquemas: Es una agrupación lógica dentro de una base de datos. Para separar objetos
organizandolos por usuario, o aplicativo o cualquier otra organización que consideremos
oportuna.
• Tablespaces: ubicaciones alternativas a la que por defecto tiene el cluster. Por defecto no se
crea ninguno.
• Roles: engloba el concepto de usuarios (roles de login) y grupos de permisos (roles de
grupo). Hasta la versión 8 de Postgres no se podían anidar roles, ahora si. Por defecto, si al
crear el cluster no se ha indicado otro usuario, se crea el usuario postgres como
superusuario.
Hay que tener en cuenta:
• Todos los usuarios son comunes a las bases de datos del cluster, se pueden conectar con
cualquiera de las bases de datos.
• Las bases de datos son independientes entre ellas, no se pueden ver objetos de una base de
datos desde otra base de datos, excepto si se usan módulos externos como dblink o dbi-link.
Entonces una organización recomendable pudiera ser:
◦ si es un servidor que acoge proyectos separados y no se han de interrelacionar:
▪ separación en bases de datos distintas.
◦ si es un servidor de proyectos con recursos comunes: una única base de datos y distintos
▪ esquemas para cada proyecto.
Jerarquía de Objetos a nivel lógico
Veamos aquí una breve descripción de los objetos tal como salen en el pgAdmin3:
• Servidores
◦ Bases de datos (template0, template1 y postgres)
▪ Cast: conversiones entre tipos de datos
▪ Lenguajes : Lenguajes procedurales para la creación de funciones
▪ Esquemas
• Agregados: definir funciones de agregación
-12-

13. • Conversiones: definir nuevas conversiones de codificación de caracteres
• Dominios: crear dominios que se pueden usar en la definición de tablas
• Funciones
• Funciones disparadoras
• Operadores
• Operador de clases
• Secuencias
• Tablas
• Tipos de datos
• Vistas
▪ Replicación : En el pgAdmin3 esto hace referencia a un esquema especial en el que
se crean los objetos para la replicación a través de Slony I
◦ Tablespaces
◦ Roles de grupo (roles)
◦ Roles de login (usuarios)
-13-

14. Instalando PostgreSQL
PostgreSQL se puede instalar en muchas plataformas, las más conocidas Windows y Linux, en este
manual vamos a ver cómo instalarlo en Linux.
Podemos instalar desde:
• Desde los fuentes
• Usando un instalador (Cortesía de la empresa EnterpriseDB)
• Desde los repositorios de nuestra distribución
• Desde los repositorios oficiales de PostgreSQL (Cortesía de la empresa CommandPropmt)
Los fuentes, el instalador y los repositorios oficiales los podemos encontrar en
http://www.postgresql.org
Instalando desde los fuentes
Requisitos
• Compilador gcc
• readline-devel
• zlib-devel
• openssl (solo si queremos que las conexiones usen SSL)
• libxml2-devel (solo si queremos instalar con soporte para XML)
• gettext (solo si se quiere NLS)
Procedimiento de instalación
• Crear el usuario postgres (como root)
• ./configure
• make
• make install (como root)
• chown -R postgres.postgres /ruta/instalacion (como root)
• cd /ruta/instalacion
• bin/initdb -D /ruta/carpeta/data
• cp contrib/start-scripts/linux /etc/init.d/postgresql
• Crear los enlaces en las carpetas de arranque apropiadas
◦ ln -s /etc/init.d/postgresql S98pgsql
◦ o usar: chkconfig --add postgresql
Este método tiene como inconveniente la dificultad de implantación, ya que requiere que el
instalador se plantee una serie de requerimientos, así como se deben realizar operaciones que
requieren estar famililiarizados con el sistema operativo, aunque en la documentación explican paso
a paso todo lo que hay que hacer.
Las ventajas, en cambio, son muchas:
• instalación controlada totalmente
• fijamos la ubicación de todos los directorios y ficheros, tanto los del programa como los de
los datos.
-14-

15. • podemos instalar características opcionales: soporte extendido para tipos de datos, soporte
nativo de idiomas, etc.
• podemos instalar paquetes opcionales: tcl/tk, python, java, perl, PAM, OpenSSL, etc.
• total flexibilidad para configurar a gusto del administrador.
Crear el usuario postgres
Para crear el usuario dueño de la instalación de la base de datos (usualmente postgres), ejecutamos
la siguiente orden como root:
adduser --home /home/postgres postgres
./configure
Luego debemos configurar los fuentes para que se ajusten a la arquiterctura de nuestro servidor así
como para que se adapte a, o para que nos diga que no podemos instalar debido a, las versiones de
las herramientas que estemos usando. También aprovechamos esta opción para forzar ciertas
opciones (para ver todas las opciones disponibles usamos ./configure --help).
./configure [opciones]
Algunas opciones son:
--prefix=/ruta/donde/se/instalará/postgres
--with-pgport=5432
--enable-nls[=lenguaje]
(ejemplo: es)
--with-perl
--with-python
--with-krb5
--with-ldap
--with-openssl
--with-libxml
--with-blocksize=Tamaño de una pagina de disco en kb
--with-segsize=Tamaño máximo de un archivo en GB
(cuando postgres alcanza este tamaño de archivo crea uno nuevo para seguir
almacenando los datos de la tabla)
--with-wal-blocksize=Tamaño de una página de disco para el WAL en kb
--with-wal-segsize=Tamaño cada archivo (segmento) del WAL en Mb
make
Compila los binarios de PostgreSQL, usando la información de configuración que le hemos dado.
Una vez terminada la compilación podemos verificar que todo esté bien usando la orden make
check, comando con el cual se realizará una serie de pruebas para verificar que todas las
características de postgres esten funcionando apropiadamente.
make install
Con esta orden se creará la carpeta en la que se va a instalar postgres (la que indicamos en la opción
./configure --prefix o /usr/local/pgsql sino indicamos nada).
Esta orden debe ejecutarse con permisos de root si la carpeta en la que se instalará postgres no esta
disponible para este usuario debido a permisos de escritura. Luego deberemos darle tales permisos
al usuario postgres sobre la carpeta que se cree.
Eso lo hacemos mediante la orden: chown -R postgres.postgres /ruta/instalacion
-15-

16. initdb
Después de instalar PostgreSQL, lo primero que hay que realizar en la creación de un cluster,
teniendo en cuenta que en un servidor, se pueden crear todos los cluster que se quiera siempre que
escuchen por puertos distintos.
initdb [opciones]
Algunas opciones son:
-D directorio | --pgdata=directorio: directorio donde se crea el cluster, si no se indica, usa lo
que establezca la variable de entorno PGDATA
-E juego_caracteres | --encoding=juego_caracteres: si no se indica, usa el del SO
--locale=ubicación: ubicación geográfica, se puede concretar más:
--lc-collate = ubicación: ordenamiento
--lc_ctype = ubicación: clasificación de caracteres
--lc_messages = ubicación: mensajes (se puede cambiar luego)
--lc-monetary = locale (se puede cambiar luego)
--lc-numeric = locale (se puede cambiar luego)
--lc-time = locale (se puede cambiar luego)
-U usuario | --username=usuario: superusuario del cluster
-W | --pwprompt: pide una contraseña que se establecerá para el nuevo superusuario
Instalación desde repositorios
La instalación a partir de los repositorios de una distribución determinada tiene sus ventajas e
inconvenientes:
Ventajas:
• Facilidad de implantación, los archivos van a directorios predeterminados. Es un buen
método para tener instalado PostgreSQL con poco esfuerzo y ponerse a practicar.
• Se crea automáticamente toda la infraestructura de funcionamiento, el usuario del sistema
operativo, los programas de arranque y parada en el init.d, etc.
• Crea una instancia de base de datos, cluster.
• Incluso en algunas distribuciones , viene como una opción más que se puede instalar.
Inconvenientes:
• Poca flexibilidad, no podemos elegir en qué directorios instalar, aunque suele ser suficiente
• No suelen venir las últimas versiones en el caso de que vengan suministrados por la
distribución, aunque probablemente en la web de PostgreSQL o en la de la distribución ya
tengan el paquete preparado para la última versión.
Procedimiento instalación
• yum install postgresql-*
◦ Donde postgresql-* representa a uno o varios paquetes que podemos instalar
▪ Podemos ver que paquetes hay disponibles para instalar con: yum search postgresql
También podemos usar los repositorios propios de postgres (con paquetes para centos, fedora y
-16-

17. redhat)
• Descargar el archivo apropiado desde: http://yum.pgsqlrpms.org
• rpm -ivh archivo_descargado
• Instalar postgres usando yum
◦ yum install postgresql-*
◦ Donde postgresql-* representa a uno o varios paquetes que podemos instalar
▪ Podemos ver que paquetes hay disponibles para instalar con: yum search postgresql
Instalación desde el instalador
Tiene las misma ventajas que instalar desde el repositorio pero sin los inconvenientes (aunque no es
tan flexible como instalar desde los fuentes suele ser suficiente). Además el instalador incluye una
herramienta llamada Stack Builder que nos permite descargar e instalar algunos módulos y
herramientas adicionales.
Procedimiento instalación
• Descargar el instalador apropiado para nuestro SO desde http://www.postgresql.org
• ejcutar en una ventana de terminal como root: ./nombre_instalador
◦ A partir de ahí seguiremos las indicaciones del instalador, generalmente será cuestion de
solo presionar siguiente hasta el final.
Actualización
Versiones menores
Son aquellas en las que solo cambio el último número de la versión, por ejemplo 8.4.1 y 8.4.2 son
versiones menores de la versión 8.4.
En este caso solo es necesario re-compilar e instalar los binarios en el mismo directorio donde se
instalarón originalmente y reiniciar el servicio de PostgreSQL. Debemos tener cuidado de usar las
mismas opciones en ./configure, podemos saber que opciones usamos originalmente con el
comando pg_config.
Versiones mayores
Son aquellas en las que cambia el primer y/o segundo dígito de la versión, por ejemplo: 8.3 y 8.4
son versiones mayores diferentes.
Para actualizar a versiones mayores es necesario sacar un respaldo de los datos, reinstalar
reinicializar el directorio de instalacion usando el initdb de la nueva versión y restaurar los datos.
Estructura física
Luego de inicializar el cluster (esto lo hacen automaticamente los paquetes y el instalador y lo
hacemos manualmente mediante la orden “initdb”), se crean una serie de directorios y archivos
dentro de la carpeta data (que usualmente la llamaremos: $PGDATA).
-17-

18. Archivos
• postgresql.conf: fichero de configuración principal, contiene la asignación a los parámetros
que configuran el funcionamiento global del servidor.
• pg_hba.conf: fichero de configuración de la autenticación de los clientes y usuarios y del
acceso a las bases de datos del cluster.
• pg_ident.conf: fichero accesorio al anterior, determina como se realiza la autenticación ident
que contiene la correspondencia entre usuarios del Sistema Operativo y de PostgreSQL.
• PG_VERSION: fichero de texto con la versión de software Postgres que crea el cluster .
• Otros archivos:
◦ postmaster.pid: se crea cuando el postmaster arranca, contiene el PID del proceso
postmaster.
◦ postmaster.opts. contiene las opciones con las que se ha iniciado el postmaster.
◦ recovery.conf, recovery.done: si se quiere o se ha hecho una recuperación.
Directorios
• base: las plantillas y las bases de datos. contiene un directorio por cada base de datos, dentro
hay un fichero por cada tabla o índice de una base de datos, los números corresponden a los
OIDs de las tablas o índices.
◦ template0: contiene las definiciones de las tablas del sistema, vistas, funciones y tipos
estándar. Nunca se debe modificar ni intentar conectarse a ella, ya que está por si
template1 se corrompe.
◦ template1: base de datos plantilla para crear nuevas bases de datos, se puede modificar
su estructura, añadiendo tablas, índices, funciones, etc. Es la que se usará como plantilla
para crear otras bases de datos.
◦ postgres: una base de datos administrativa.
• global: tablas e indices del catálogo comunes a todas las bases de datos.
◦ catálogo compartido: pg_auth (autorizaciones), pg_database, etc.
◦ pgstat.stat: fichero usado por el monitor de estadísticas.
◦ pg_control: fichero con parámetros del cluster, algunos inmutables (establecidos en la
creación del cluster) y otros variables (establecidos en la puesta en marcha).
• pg_log: archivos de log entendible por humanos.
• pg_xlog: archivos de log transaccional (WAL).
• pg_clog: archivo de estado para las transacciones (estado de cada transacción).
◦ El estado de una transacción puede ser: confirmada, en progreso o abortada.
• pg_multixact: contiene datos sobre el estado multi-transaccional, usado para los bloqueos
compartidos de filas.
• pg_twophase: ficheros de estado para las transacciones preparadas. Se usa en COMMIT en
dos fases.
• pg_subtrans: para realizar los “savepoints” en medio de transacciones.
• pg_tblspc: información sobre los tablespaces. Enlaces a los directorios donde esta montado
el tablespace.
• pg_stat_tmp: Contiene temporalmente las estadísticas que se recojen en tiempo de ejecución
que luego se escriben a los catálogos del sistema.
-18-

19. Aplicaciones instaladas
Aplicaciones cliente
• clusterdb: equivalente al comando CLUSTER de SQL, reorganiza cluster de tablas.
• createdb: crea una base de datos.
• createlang: define un nuevo lenguaje procedural en una base de datos.
• createuser: creación de usuarios.
• dropdb: borrar una base de datos.
• droplang: borrar un lenguaje procedural.
• dropuser: borrar un usuario.
• ecpg: SQL C preprocesador embebido.
• pg_config: recupera información sobre la versión instalada de PostgreSQL.
• pg_dump: extrae una base de datos en un fichero script o en otros formatos.
• pg_dumpall: extrae un cluster de base de datos en un fichero script.
• pg_restore: restaura una base de datos desde un fichero creado con pg_dump (siempre que
no sea texto plano).
• psql: terminal interactivo de PostgreSQL. Es la herramienta canónica para la ejecución de
sentencias SQL a través del shell del SO Es una herramienta de tipo frontend que permite
describir sentencias SQL, ejecutarlas y visualizar sus resultados El método de ingreso puede
ser mediante la inserción directa del código en la consola, o la ejecución de sentencias
dentro de un archivo de texto Provee diversos meta-comandos para la ejecución de las
sentencias, así como diversas opciones tipo shell propias de la herramienta
• reindexdb: reindexa una base de datos.
• vacuumdb: reorganiza y analiza una base de datos.
Aplicaciones servidor
• initdb: crea un cluster de base de datos.
• pg_controldata: muestra información de control de un cluster de base de datos.
• pg_ctl: inicia, para o reinicia un servidor PostgreSQL.
• pg_resetxlog: reinicia el “write-ahead log” y otras informaciones de control de un cluster de
base de datos.
• postgres: Proceso postmaster principal
• postmaster: enlace simbólico a la aplicación postgres, está solo para mantener
compatibilidad con versiones anteriores.
Módulos adicionales
La distribución oficial de postgres viene con ciertos módulos adicionales que pueden ser útiles.
Algunos módulos interesantes son:
auto_explain Permite ejecutar EXPLAIN sobre las consultas que se están ejecutando en la base
de datos de forma automática
citext Tipo de dato text que no distingue entre mayúsculas y minúsculas
dblink Permite conectarse con otras bases de datos postgresql
pgbench Se usa para pruebas de rendimiento simples
-19-

20. pg_standby Permite tener un servidor en modo de recuperación permanente
start-scripts Scripts de inicio para usar en varios SO
Para instalarlos podemos seguir el siguiente procedimiento:
Si instalamos desde los fuentes
• Nos ubicamos en el directorio contrib de la distribución de postgres
• pasamos a la carpeta del módulo que deseamos instalar
• make
• make install
• Vea el archivo README de cada modulo para saber si requiere algún paso adicional para
ese módulo en particular.
Si instalamos desde los repositorios
• Los módulos contrib se instalan ejecutando: yum install postgresql-contrib
• Vea el archivo README de cada modulo para saber si requiere algún paso adicional para
ese módulo en particular.
Si instalamos desde el instalador
• Vea el archivo README de cada modulo para saber si requiere algún paso adicional para
ese módulo en particular.
-20-

21. Configuración del Servidor
Párametros del Kernel
La instalación de PostgreSQL requiere la comprobación de que el servidor será capaz de soportarlo.
Normalmente, los valores por defecto en la mayoría de los párametros son suficientes, no asi
SHMMAX que es demasiado bajo. Es tarea del administrador de sistemas cambiar los valores de
los parámetros que sea necesario. Si el sistema no puede proporcionar los recursos que requiere el
servidor, éste no se puede poner en marcha y devuelve un error.
El únicos párametros que normalmente requieren cambios son: SHMMAX y OVERCOMMIT.
Para cambiar los valores de estos párametros agregaremos las siguientes líneas en el archivo
/etc/sysctl.conf y luego reiniciaremos el sistema:
kernel.shmmax=<valor proporcionado por el mensaje de error cuando no quizo levantar>
vm.overcommit_memory=2
Consideraciones sobre el Sistema de Discos
Puesto que el sistema de discos es la parte mas lenta de todo sistema, se recomienda los siguientes
puntos al configurar el servidor.
• Configuración RAID
◦ En la comunidad se ha recomendado el nivel 10
• Apagar cache de escritura o usar battery backed array controllers
• Distribución de los discos
◦ Poner el WAL ($PGDATADIR/pg_xlog) en un disco aparte
◦ Si es posible; disponer de discos separados para poner los datos, índices y archivos
temporales.
Archivos de configuración de PostgreSQL
PostgreSQL tiene tres archivos de configuración, los cuales mencionamos cuando vimos los
archivos que crea postgresql en el cluster.
postgresql.conf
Ubicación de ficheros
data_directory = ‘ConfigDir’ ConfigDir representa $PGDATA
hba_file = 'ConfigDir/pg_hba.conf' fichero de configuración de autenticación
ident_file = 'ConfigDir/pg_ident.conf' fichero de configuración de la autenticación
external_pid_file = ‘(none)’ nombre del fichero pid
Conexión
listen_adresses= 'localhost' especifica las direcciones IP que el servidor debe
escuchar desde aplicaciones cliente. Lista separada por
comas, si está vacía no acepta conexiones por red, si es
-21-

22. ‘*’ acepta cualquier dirección.
port = 5432 puerto TCP/IP donde escucha postmaster
max_connections = 100 máximo de sesiones concurrentes (100)
superuser_reserved_connections = 3 conexiones reservadas para superusuarios
unix_socket_directory = '' indica donde se encuentran los socket del dominio local
para las conexiones locales (/tmp)
unix_socket_group = ''
unix_socket_permissions = 0777 si ponemos 0700 solo dejamos conectar al usuario
postgres
bonjour_name = ‘’
Seguridad y autenticado
authentication_timeout = 1min tiempo máximo en segundos para completar el
autenticado del cliente
ssl = off si el postmaster negocia con clientes que usen
conexiones ssl
ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:! Cifrados SSL permitidos
MD5:@STRENGTH'
password_encryption = on cómo se almacena por defecto una palabra de paso (on,
encriptada)
db_user_namespace = off Vincula a los usuarios a una base de datos específica
krb_server_keyfile = '' configura el modo de usar el autenticado con Kerberos
krb_svrname = 'postgres'
krb_caseins_users = off
TCP Keepalives
tcp_keepalives_idle = 0 controla si las conexiones siguen vivas,
tcp_keepalives_interval = 0 para matarlas si no responden
tcp_keepalives_count = 0
Uso de recursos : Memoria
shared_buffers = 32MB Tamaño de la memoria compartida
temp_buffers = 8MB Máximo de memoria a utilizar para buffers temporales
que una sesión puede usar, se usan para acceder a las
tablas temporales
max_prepared_transactions = 0 número máximo de transacciones preparadas permitidas
simultáneamente. Se recomienda que sean al menos
igual a max_connections si se desean usar
work_mem = 1MB cantidad de memoria total que se usará para
operaciones de ordenación y hash antes de usar
-22-

23. archivos temporales en disco
maintenance_work_mem = 16MB cantidad máxima de memoria que se usará para
operaciones de mantenimiento
max_stack_depth = 2MB profundidad máxima de seguridad de la pila de
ejecución del servidor (ver ulimit –s)
Uso de recursos del kernel
max_files_per_process = 1000 no máximo de ficheros abiertos por cada proceso
servidor. Si aparece el error en el
SO de “too many files” reducir este valor o cambiar el
kernel
shared_preload_libraries = '' especifica las librerias compartidas que deben cargarse
en la puesta en marcha del servidor
Retraso del vacuum basado en costo
vacuum_cost_delay = 0ms tiempo en ms que se duerme el proceso vacuum cuando
se ha excedido el vacuum_cost_limit
vacuum_cost_page_hit = 1 coste estimado de limpiar un buffer del cache de BD,
bloquear la pila del buffer, actualizar la tabla
compartida hash, y escanear el contenido de la página
vacuum_cost_page_miss = 10 coste estimado en limpiar un buffer que tiene que ser
leido del disco, bloquear la pila del buffer, actualizar la
tabla compartida hash, leer el bloque desde disco y
escanear el contenido de la página
vacuum_cost_page_dirty = 20 coste estimado cuando la limpieza modifica un buffer
limpio dejándolo sucio. Trabajo extra de llevar el buffer
a disco
vacuum_cost_limit = 200 coste acumulado que hace que el vacuum se pare
momentáneamente
Configuración del proceso bgwriter
bgwriter_delay = 200ms tiempo en ms entre cada puesta en marcha del proceso
bgwriter_lru_maxpages = 100 no de buferes que serán escritos por el método de estar
próximo su reciclado
bgwriter_lru_multiplier = 2.0 porcentaje de bufferes que están próximos su reciclado
y escribe los que están sucios
Comportamiento asincrónico
effective_io_concurrency = 1
Write Ahead Log
fsync = on determina si PostgreSQL debe forzar al SO a escribir en
disco, jamas se debe apagar
-23-

24. synchronous_commit = on
wal_sync_method = fsync método que usa el gestor WAL para forzar la escritura
de los buffers en disco. Posibles valores: fsync,
fdatasunc, open_sync, open_datasync,
fsync_writethrough (de forma predeterminada usa el
primero soportado por el SO)
full_pages_writes = on establece si se copia el bloque entero al diario después
de la primera modificación que sufra o no, después de
un punto de verificación (por defecto está a on, para
evitar problemas de corrupción de bloques).
wal_buffers = 64kB cantidad de buffers para los diarios que forman la cache
de la WAL
wal_writer_delay = 200ms
commit_delay = 0 tiempo en microsegundos que espera el servidor para
llevar las entradas del buffer de diario a los diarios
después de que una transacción se confirme. Permite
que otros procesos puedan aprovechar esta operación, es
decir, que se haga un solo commit para varias
transacciones.
commit_siblings = 5 no mínimo de transacciones activas que debe de haber
para que el gestor WAL se espere el tiempo indicado en
commit_delay
Checkpoints
checkpoint_segments = 3 distancia máxima entre puntos de verificación
automáticos, medida en no de ficheros. Los diarios
están divididos en segmentos de 16Mb, cuando se han
llenado el no de segmentos de este parámetro, se realiza
un punto de verificación y así el sistema puede
reutilizar los segmentos
checkpoint_timeout = 5min tiempo máximo entre la realización de un punto de
verificación y el siguiente
checkpoint_warning = 30s escribe un mensaje en el fichero de seguimiento si un
punto de verificación se lanza antes del intervalo dado
en este parámetro, si es 0 se deshabilita el warning
checkpoint_completion_target = 0.5 Factor para determinar la duración del checkpoint
Archivado del WAL
archive_mode = off
archive_command = instrucción del SO que se debe ejecutar para archivar un
segmento completado del WAL. Por ejemplo: ‘cp
%p /mnt/archivedir/%f’ donde %p es el camino
completo al fichero y %f el nombre
-24-

25. archive_timeout = 0 Fuerza el archivado pasado este tiempo
Método de planificación y optimización
enable_bitmapscan = on habilita o deshabilita el uso de tipos de planes de
escaneo en bitmaps
enable_hashagg = on habilita o deshabilita el uso de tipos de planes de
agregación por dispersión
enable_hashjoin = on habilita o deshabilita el uso de tipos de planes
concatenación
enable_indexscan = on habilita o deshabilita el uso de planes de recorrido en
índice
enable_mergejoin = on habilita o deshabilita el uso de tipos de planes de
concatenación por fusión
enable_nestloop = on habilita o deshabilita el uso de tipos de planes de
concatenación de bucles anidados
enable_seqscan = on habilita o deshabilita el uso de tipos de planes de
recorrido secuencial (full scan)
enable_sort = on habilita o deshabilita el uso de pasos de ordenación
explícitos
enable_tidscan = on habilita o deshabilita el uso de planes del rastreo TID en
el planificador. Se usa un rastreo TID cuando la pseudo-
columna CTID aparece en un WHERE CTID es la
localización física de una fila
Constantes de costeo para la planeación
seq_page_cost = 1.0
random_page_cost = 4 indica el coste de cargar una página al azar en cache
(4). Se supone que el coste de carga de una página
secuencial es 1
cpu_tuple_cost = 0.01 indica el coste de procesar una tupla en una página de
datos (0.01)
cpu_index_tuple_cost = 0.005 indica el coste de procesar una entrada en una página de
índice (0.001)
cpu_operator_cost = 0.0025 indica el coste de procesar un operador (0.0025)
effective_cache_size = 128MB tamaño efectivo de la cache de disco disponible para
realizar un rastreo con índice. Valor alto aumenta la
probabilidad de rastreo con índice, en caso contrario,
será secuencial
GEQO (Genetic Query Optimizer)
geqo = on PostgreSQL usa el optimizador genético cuando
considera que es muy costoso hacer una planeación
-25-

26. exhaustiva.
geqo_threshold = 12 indica el no de items en el FROM a partir del cual se
debe usar GEQO
geqo_effort = 5 controla el compromiso entre el tiempo de planificación
y la eficiencia del plan de ejecución (entero entre 1 y
10)
geqo_pool_size = 0 indica el no de individuos de una población (al menos
2, valor típico entre 100 y 1000). Si es 0, el valor por
defecto adecuado se elige en función de geqo_effort
geqo_generations = 0 indica el valor para las generaciones (iteraciones del
algoritmo). Es un valor entero, si es 0 se calcula con la
fórmula: geqo_effort*Log2(geqo_pool_size)
geqo_selection_bias = 2.0 indica la presión selectiva dentro de la población (entre
1.5 y 2.0)
Otras opciones para la planeación
default_statistics_target = 100 establece el objetivo estadístico por defecto para los
columnas de las tablas que no lo tienen definido
explícitamente con ALTER TABLE SET
STATISTICS).
constraint_exclusion = partition establece si el optmizador debe utilizar las restricciones
para realizar la optimización
cursor_tuple_fraction = 0.1
from_collapse_limit = 8 establece si el optimizador debe fusionar subconsultas
en las consultas si los items en el FROM está por
debajo del valor dado
join_collapse_limit = 8
Configuración del log
log_destination = 'stderr' existen varios métodos para emitir los mensajes del
servidor (stderr, csvlog, syslog y eventlog)
logging_collector = on permite enviar los errores enviados a stderr a los
ficheros de seguimiento
log_directory = 'pg_log' si el parámetro anterior está habilitado determina el
directorio donde se crean los ficheros de seguimiento
log_filename = 'postgresql-%Y-%m-%d_ nombre de los ficheros de seguimiento
%H%M%S.log'
log_truncate_on_rotation = off establece la rotación de ficheros, aunque se pueden usar
alternativas
log_rotation_age = 1d si redirect_stderr = on establece la duración máxima de
cada fichero de seguimiento, con 0 deshabilita esta
opción
-26-

27. log_rotation_size = 10MB tamaño de los ficheros rotados
syslog_facility = 'LOCAL0' si el seguimiento lo hace syslog, aquí se determina qué
utilidad se usa
syslog_ident = 'postgres' si se usa syslog este es el nombre del programa
utilizado para identificar los mensajes de PostgreSQL.
silent_mode = off la salida estándar y los errores se envían a /dev/null
client_min_messages = notice establece el nivel de los mensajes que serán enviados a
los clientes
log_min_messages = warning controla el nivel de los mensajes que son escritos en el
fichero de seguimiento
log_error_verbosity = default controla el detalle de la información que se escribe en
el fichero de seguimiento (terse, default, verbose), cada
nivel añade más campos
log_min_error_statement = error controla si la instrucción SQL que ha provocado el
error debe ser recordada o no el el fichero de
seguimiento.
log_min_duration_statement = -1 registra las instrucciones y su duración si su ejecución
tarda más que el indicado aquí. Con 0 registra todas y
con -1 ninguna
debug_print_parse = off configuran el servidor para que registre de cada
consulta información de su ejecución
debug_print_rewritten = off
debug_print_plan = off
debug_pretty_print = off
log_checkpoints = off
log_connections = off información detallada de cada conexión
log_disconnections = off información detallada de cada desconexión
log_duration = off registra la duración de cada instrucción que va a ser
registrada
log_hostname = off con esta opción, aparte de la IP, se registra también el
nombre del host desde donde se establece la conexión
log_line_prefix = '' escribe una cadena antes de cada línea de informe.
log_lock_waits = off Muestra las esperas de bloqueos mayores o igual a
deadlock_timeout
log_statement = 'none' controla qué instrucciones son registradas (none, ddl,
mod y all)
log_temp_files = -1 Se indica el tamaño en kB. -1 es desactivado y 0
muestra todos.
log_timezone = unknown
-27-

28. Estadísticas
track_activities = on
track_counts = on
track_functions = none none, pl, all
track_activity_query_size = 1024
update_process_title = on
stats_temp_directory = 'pg_stat_tmp'
log_parser_stats = off
log_planner_stats = off
log_executor_stats = off
log_statement_stats = off
Autovacuum
autovacuum = on si el servidor debe lanzar el proceso autovacuum
log_autovacuum_min_duration = -1
autovacuum_max_workers = 3
autovacuum_naptime = 1min periodo de parada en segundos entre dos puestas en
marcha del autovacuum
autovacuum_vacuum_threshold =50 no mínimo de filas modificadas o borradas para lanzar
el autovacuum. Este valor se puede sobreescribir para
tablas individuales incluyendo información en
pg_autovacuum.
autovacuum_analyze_threshold = 50 especifica el no mínimo de filas modificadas o borradas
para lanzar un analyze sobre una tabla. Este valor se
puede sobreescribir para tablas individuales incluyendo
información en pg_autovacuum.
autovacuum_vacuum_scale_factor = 0.2 especifica la fracción del tanmaño de la tabla que se
debe añadir a autovacuum_vacuum_thershold para
decidir si se lanza la purga.
autovacuum_analyze_scale_factor = 0.1 especifica la fracción del tanmaño de la tabla que se
debe añadir a autovacuum_analyze_thershold para
decidir si se lanza el analyze.
autovacuum_freeze_max_age = Máximo valor de XID antes de forzar un vacuum
200000000
autovacuum_vacuum_cost_delay = 20 especifica el coste de retraso que se debe utilizar en las
operaciones autovacuum. Si es -1 se usa
vacuum_cost_delay. Este valor se puede sobreescribir
para tablas individuales incluyendo información en
pg_autovacuum.
autovacuum_vacuum_cost_limit = -1
-28-

29. Predeterminados para las conexiones cliente
search_path = '$user,public' órden de búsqueda de esquemas de la base de datos
default_tablespace = '' tablespace donde se crearan los objetos si no se indica
otro
temp_tablespaces = '' una lista de tablespaces para crear objetos temporales
check_function_bodies = on habilita la validación de los cuerpos de las funciones
que se crean
default_transaction_isolation = 'read establece el nivel de aislamiento por defecto
committed'
default_transaction_read_only = off establece cómo son las nuevas transacciones,
‘read_only’ o ‘read/write’. Las transacciones read_only
solo pueden modificar tablas temporales.
session_replication_role = 'origin'
statement_timeout = 0 se abortará cualquier instrucción cuya ejecución supere
este límite. 0 deshabilita esta opción.
vacuum_freeze_min_age = 50000000
vacuum_freeze_table_age = 150000000
xmlbinary = 'base64'
xmloption = 'content'
Localización y formato
datestyle = 'iso, mdy' comportamiento del servidor asociado a
intervalstyle = 'postgres'
timezone = unknown valores geográficos y de tiempo. Si no se
timezone_abbreviations = 'Default' configuran , se usan los valores del entorno.
extra_float_digits = 0
client_encoding = sql_ascii cambiar
lc_messages = 'es_EC.UTF-8'
lc_monetary = 'es_EC.UTF-8'
lc_numeric = 'es_EC.UTF-8’
lc_time = 'es_EC.UTF-8'
default_text_search_config =
'pg_catalog.spanish'
dynamic_library_path = '$libdir'
local_preload_libraries = ''
Gestión de Bloqueos
deadlock_timeout = 1s tiempo que el servidor espera cuando se genera un
bloqueo para comprobar la condición de bloqueo
-29-

30. mortal.
max_locks_per_transaction = 64 la tabla de bloqueos compartida se crea para alojar un
no de bloqueos: max_locks_per_transactions
*(max_conections + max_prepared_transaction)
Compatibilidad con versiones anteriores de PostgreSQL
add_missing_from = off
array_nulls = on
backslash_quote = safe_encoding on, off, or safe_encoding
default_with_oids = off
escape_string_warning = on
regex_flavor = advanced advanced, extended, or basic
sql_inheritance = on
standard_conforming_strings = off
synchronize_seqscans = on
Compatibilidad con otras plataformas y clientes
transform_null_equals = off
Opciones especiales
custom_variable_classes = ''
pg_hba.conf
Es importante poder definir desde qué equipos se pueden conectar a nuestra base de datos, así como
poder definir qué usuarios y a qué bases de datos se pueden conectar.
La configuración de este nivel de seguridad se realiza en el archivo pg_hba.conf (hba = host based
authentication).
Se trata de editar una serie de reglas que se irán procesando de arriba abajo, cuando se encuentre
una regla que cumpla la conexión, se ejecutará lo que ponga en el método.
Hay cuatro formas generales de definir un acceso autorizado:
TIPO BASE DATOS USUARIOS DIRECCIÓN MÉTODO
LOCAL base_datos usuario método-autenticación [opción]
HOST base_datos usuario direcciónCIDR método autenticación [opción]
HOSTSSL base_datos usuario direcciónCIDR método autenticación [opción]
HOSTNOSSL base_datos usuario direcciónCIDR método autenticación [opción]
base_datos:
• ALL: se permite la conexión a cualquier base de datos
• SAMEUSER: solo a bases de datos que su nombre sea el mismo que el usuario que se
conecta
• SAMEROLE: solo a bases de datos que su nombre sea el mismo que el role que se conecta
• nombd1, nombd2,...: se permite la conexión a cualquiera de las bases de datos de la lista
• @fichero: se permite la conexión a las bases de datos incluidas en el fichero, que debe estar
-30-

31. en el mismo directorio que pg_hba.conf
usuario:
• ALL: se permite la conexión de cualquier role
• role1, [+]role2,...: se permite la conexión de los roles de la lista y además se permite la
conexión de cualquier role que sea miembre de role2
• @fichero: se permite la conexión de los roles incluidos en el fichero, que debe estar en el
mismo directorio que pg_hba.conf
método-autenticación
• TRUST: conexión aceptada sin condiciones
• REJECT: conexión rechazada sin condiciones
• PASSWORD: se solicita palabra de paso sin encriptar, las palabras de paso se almacenan en
la tabla pg_authid y pueden estar cifradas o no según como se creara el role.
• MD5: palabra de paso con el método de encriptación md5, y se almacena también con este
método. Es el método recomendado por PostgreSQL. Se obtiene un cifrado a partir de la ID
de usuario y la palabra de paso, el cliente solicita una semilla al servidor y así se obtiene un
segundo cifrado que es envíado al servidor, en el servidor se utiliza la palabra de paso
almacenada, la ID del usuario (la obtiene de la conexión) y la semilla para obtener un
cifrado similar y los compara.
• KRB5: se usa Kerberos v5 para autenticar el cliente, se ha de habilitar en la instalación del
servidor.
• IDENT correspondencia: a partir del usuario de la conexión cliente (se fía de la
autenticación del cliente) y de la correspondencia indicada en la opción, se obtiene un role
de PostgreSQL para realizar la conexión. Las correspondencias se obtienen del fichero
pg_ident.conf. La correspondencia puede ser:
◦ SAMEUSER: el usuario del sistema operativo es el mismo que se conecta a la BD.
◦ cambio-usuario: el sistema mira el fichero pg_ident.conf, y busca una fila donde esté la
correspondencia llamada ‘cambio-usuario’ y se corresponda con el usuario conectado al
SO, haciendo la conexión a la BD con el usuario con el usuario de la columna usuario-
pg.
-31-