Curso de administracion de PostgreSQL INCOP - Marzo 2010

Jaime Alberto Casanova MerchánEmail: jcasanov@systemguards.com.ec

Índice de contenidoConceptos básicos y estructura interna.................................................................................................4

El proceso Postmaster .....................................................................................................................4La memoria compartida ..................................................................................................................4WAL: Write-Ahead Log ..................................................................................................................4

¿Qué es? .....................................................................................................................................4WAL: Principios de diseño ........................................................................................................5¿Qué es un registro de WAL?......................................................................................................5Consideraciones sobre el WAL ..................................................................................................5Checkpoints ................................................................................................................................5Estructura del WAL ....................................................................................................................6Nombres de los archivos del WAL .............................................................................................6Detectando el final del WAL ......................................................................................................6

MVCC: Multi Version Concurrency Control ..................................................................................7¿Qué es? .....................................................................................................................................7Beneficios de MVCC .................................................................................................................7Implementación ..........................................................................................................................7Consideraciones sobre MVCC....................................................................................................9

Tareas de mantenimiento ..............................................................................................................10VACUUM.................................................................................................................................10VACUUM FULL ......................................................................................................................10Alternativas a VACUUM FULL ..............................................................................................10

CLUSTER ...........................................................................................................................11ALTER TABLE / SET TYPE ..............................................................................................11

ANALYZE................................................................................................................................11REINDEX ................................................................................................................................11Autovacuum .............................................................................................................................11

Concepto de “Cluster de bases de datos” en PostgreSQL.............................................................12Jerarquía de Objetos a nivel lógico...........................................................................................12

Instalando PostgreSQL ......................................................................................................................14Instalando desde los fuentes..........................................................................................................14

Requisitos .................................................................................................................................14Procedimiento de instalación....................................................................................................14

Crear el usuario postgres......................................................................................................15./configure.............................................................................................................................15make ....................................................................................................................................15make install...........................................................................................................................15initdb.....................................................................................................................................16

Instalación desde repositorios........................................................................................................16Procedimiento instalación.........................................................................................................16

Instalación desde el instalador.......................................................................................................17Procedimiento instalación.........................................................................................................17

Actualización.................................................................................................................................17Versiones menores.....................................................................................................................17Versiones mayores.....................................................................................................................17

Estructura física.............................................................................................................................17Archivos ...................................................................................................................................18Directorios.................................................................................................................................18

-2-

Aplicaciones instaladas..................................................................................................................19Aplicaciones cliente..................................................................................................................19Aplicaciones servidor................................................................................................................19Módulos adicionales.................................................................................................................19

Si instalamos desde los fuentes............................................................................................20Si instalamos desde los repositorios ....................................................................................20Si instalamos desde el instalador .........................................................................................20

Configuración del Servidor................................................................................................................21Párametros del Kernel....................................................................................................................21Consideraciones sobre el Sistema de Discos.................................................................................21Archivos de configuración de PostgreSQL...................................................................................21

postgresql.conf..........................................................................................................................21Ubicación de ficheros ..........................................................................................................21Conexión .............................................................................................................................21Seguridad y autenticado ......................................................................................................22TCP Keepalives....................................................................................................................22Uso de recursos : Memoria ..................................................................................................22Uso de recursos del kernel ...................................................................................................23Retraso del vacuum basado en costo....................................................................................23Configuración del proceso bgwriter.....................................................................................23Comportamiento asincrónico...............................................................................................23Write Ahead Log..................................................................................................................23Checkpoints .........................................................................................................................24Archivado del WAL..............................................................................................................24Método de planificación y optimización .............................................................................25Constantes de costeo para la planeación..............................................................................25GEQO (Genetic Query Optimizer) ......................................................................................25Otras opciones para la planeación........................................................................................26Configuración del log...........................................................................................................26Estadísticas ..........................................................................................................................28Autovacuum ........................................................................................................................28Predeterminados para las conexiones cliente ......................................................................29Localización y formato ........................................................................................................29Gestión de Bloqueos ............................................................................................................29Compatibilidad con versiones anteriores de PostgreSQL....................................................30Compatibilidad con otras plataformas y clientes.................................................................30Opciones especiales..............................................................................................................30

pg_hba.conf...............................................................................................................................30

-3-

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-

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-

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-

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-

Veamos un ejemplo:-- creamos una tablaCREATE TABLE t1 ( i integer, t text );

-- Insertamos algunos registros, 3 para empezarINSERT 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-

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-

• 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-

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-

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-

• 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-

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-

• 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-

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-

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-

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-

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-

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-

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-

‘*’ 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:!MD5:@STRENGTH'

Cifrados SSL permitidos

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-

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-

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-

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-

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_%H%M%S.log'

nombre de los ficheros de seguimiento

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-

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-

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 = 200000000

Máximo valor de XID antes de forzar un vacuum

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-

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 committed'

establece el nivel de aislamiento por defecto

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-

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-

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-