Administracion de Postgres

Temas a buscar
Clonacion DBs
1. Dataguard
2. Rac
3. WebLogic
4. Forms & Reports
5. Replicacion
6. Migracion
7. Cloud Control
8. DGMGRL Broker
9. Particionar Tablas
10.Mask-Data
11.Monitoreos y Graficacion de Servidores de BDs
PostgreSQL
PostgreSQL
Desarrollador(es)
PostgreSQL Global Development Group
www.postgresql.org
Informacin general
9.6.2 (info)
ltima versin estable
9 de febrero de 2017 (6 das)
Gnero Base de datos objeto-relacional (ORDBMS)
Sistema operativo Multiplataforma
Licencia PostgreSQL License1
En espaol No
PostgreSQL es un Sistema de gestin de bases de datos relacional orientado a objetos y libre,

publicado bajo la licencia PostgreSQL,1 similar a la BSD o la MIT.
Como muchos otros proyectos de cdigo abierto, el desarrollo de PostgreSQL no es

manejado por una empresa o persona, sino que es dirigido por una comunidad de
desarrolladores que trabajan de forma desinteresada, altruista, libre o apoyados por
organizaciones comerciales. Dicha comunidad es denominada el PGDG (PostgreSQL Global
Development Group).
ndice
[ocultar]
1Nombre del producto

2Historia
3Caractersticas
3.1Alta concurrencia
3.2Amplia variedad de tipos nativos
3.3Otras caractersticas
3.4Funciones
3.5Ventajas
4Productos alrededor de PostgreSQL
5Historial de liberaciones
5.1Alternativas Comerciales
5.2GIS
5.3Replicacin
5.4Herramientas de administracin
5.5Bsqueda de texto
5.6XML
6Usuarios destacados
7Premios
8Referencias
9Enlaces externos
Nombre del producto

El uso de caracteres en mayscula en el nombre PostgreSQL puede confundir a algunas
personas a primera vista. Las distintas pronunciaciones de "SQL" pueden llevar a
confusin. Los desarrolladores de PostgreSQL lo pronuncian /post s kju l/;. Es
tambin comn or abreviadamente como simplemente "Postgres", el que fue su nombre
original. Debido a su soporte del estndar SQL entre la mayor parte de bases de datos
relacionales, la comunidad consider cambiar el nombre al anterior Postgres. Sin
embargo, el PostgreSQL Core Team anunci en 2007 que el producto seguira
llamndose PostgreSQL. El nombre hace referencia a los orgenes del proyecto como la
base de datos "post-Ingres", y los autores originales tambin desarrollaron la base de
datos Ingres.
Historia
PostgreSQL ha tenido una larga evolucin, la cual se inicia en 1982 con el proyecto Ingres
en la Universidad de Berkeley. Este proyecto, liderado por Michael Stonebraker, fue uno de
los primeros intentos en implementar un motor de base de datos relacional. Despus de
haber trabajado un largo tiempo en Ingres y de haber tenido una experiencia comercial
con el mismo, Michael decidi volver a la Universidad en 1985 para trabajar en un nuevo
proyecto sobre la experiencia de Ingres, dicho proyecto fue llamado post-ingres o
simplemente POSTGRES.
El proyecto post-ingres pretenda resolver los problemas con el modelo de base de datos
relacional que haban sido aclarados a comienzos de los aos 1980. El principal de estos
problemas era la incapacidad del modelo relacional de comprender "tipos", es decir,
combinaciones de datos simples que conforman una nica unidad. Actualmente estos son
llamados objetos. Se esforzaron en introducir la menor cantidad posible de funcionalidades
para completar el soporte de tipos. Estas funcionalidades incluan la habilidad de definir
tipos, pero tambin la habilidad de describir relaciones - las cuales hasta ese momento
eran ampliamente utilizadas pero mantenidas completamente por el usuario. En Postgres
la base de datos comprenda las relaciones y poda obtener informacin de tablas
relacionadas utilizando reglas. Postgres us muchas ideas de Ingres pero no su cdigo.
La siguiente lista muestra los hitos ms importantes en la vida del proyecto Postgres.
1986: se publicaron varios papers que describan las bases del sistema.
1988: ya se contaba con una versin utilizable.
1989: el grupo publicaba la versin 1 para una pequea comunidad de usuarios.
1990: se publicaba la versin 2 la cual tena prcticamente reescrito el sistema de reglas.
1991: publicacin de la versin 3, esta aada la capacidad de mltiples motores de
almacenamiento.
1993: crecimiento importante de la comunidad de usuarios, la cual demandaba ms
caractersticas.
1994: despus de la publicacin de la versin 4, el proyecto termin y el grupo se disolvi.
Despus de que el proyecto POSTGRES terminara, dos graduados de la universidad,
Andrew Yu y Jolly Chen, comenzaron a trabajar sobre el cdigo de POSTGRES, esto fue
posible dado que POSTGRES estaba licenciado bajo la BSD, y lo primero que hicieron fue
aadir soporte para el lenguaje SQL a POSTGRES, dado que anteriormente contaba con
un intrprete del lenguaje de consultas QUEL (basado en Ingres), creando as el sistema al
cual denominaron Postgres95.
Para el ao 1996 se unieron al proyecto personas ajenas a la Universidad como Marc

Fournier de Hub.Org Networking Services, Bruce Momjian y Vadim B. Mikheev quienes
proporcionaron el primer servidor de desarrollo no universitario para el esfuerzo de
desarrollo de cdigo abierto y comenzaron a trabajar para estabilizar el cdigo de
Postgres95.
En el ao 1996 decidieron cambiar el nombre de Postgres95 de tal modo que refleje la

caracterstica del lenguaje SQL y lo terminaron llamando PostgreSQL, cuya primera
versin de cdigo abierto fue lanzada el 1 de agosto de 1996. La primera versin formal
de PostgreSQL (6.0) fue liberada en enero de 1997. Desde entonces, muchos
desarrolladores entusiastas de los motores de base de datos se unieron al proyecto,
coordinaron va Internet y entre todos comenzaron a incorporar muchas caractersticas al
motor.
Aunque la licencia permita la comercializacin de PostgreSQL, el cdigo no se desarroll
en principio con fines comerciales, algo sorprendente considerando las ventajas que
PostgreSQL ofreca. La principal derivacin se origin cuando Paula Hawthtorn (un
miembro del equipo original de Ingres que se pas a Postgres) y Michael Stonebraker
conformaron Illustra Information Technologies para comercializar Postgres.
En 2000, ex inversionistas de Red Hat crearon la empresa Great Bridge para comercializar
PostgreSQL y competir contra proveedores comerciales de bases de datos. Great Bridge
auspici a varios desarrolladores de PostgreSQL y don recursos de vuelta a la
comunidad, pero a fines de 2001 cerr debido a la dura competencia de compaas como
Red Hat y pobres condiciones del mercado.
En 2001, Command Prompt, Inc. lanz Mammonth PostgreSQL, la ms antigua

distribucin comercial de PostgreSQL. Contina brindando soporte a la comunidad
PostgreSQL a travs del auspicio de desarrolladores y proyectos, incluyendo PL/Perl,
PL/php y el alojamiento de proyectos de comunidades como PostgreSQL Build Farm.
En enero de 2005, PostgreSQL recibi apoyo del proveedor de base de datos Pervasive
Software, conocido por su producto Btrieve que se utilizaba en la plataforma Novell
Netware. Pervasive anunci soporte comercial y participacin comunitaria y logr algo de
xito. Sin embargo, en julio de 2006 dej el mercado de soporte de PostgreSQL.
A mediados de 2005 otras dos compaas anunciaron planes para comercializar

PostgreSQL con nfasis en nichos separados de mercados. EnterpriseDB aadi
funcionalidades que le permitan a las aplicaciones escritas para trabajar con Oracle ser
ms fciles de ejecutar con PostgreSQL. Greenplum contribuy mejoras directamente
orientadas a aplicaciones de Data Warehouse e Inteligencia de negocios, incluyendo el
proyecto BizGres.
En octubre de 2005, John Loiacono, vicepresidente ejecutivo de software en Sun

Microsystems coment: "No estamos yendo tras el OEM de Microsoft pero estamos viendo
a PostgreSQL ahora", aunque no se dieron especificaciones en ese momento. Para
noviembre de 2005, Sun Solaris 10 (lanzamiento 6/06) inclua PostgreSQL.
En agosto de 2007 EnterpriseDB anunci el Postgres Resource Center y EnterpriseDB

Postgres, diseados para ser una completamente configurada distribucin de PostgreSQL
incluyendo muchos mdulos contribuidos y agregados. EnterpriseDB Postgres fue
renombrado Postgres Plus en marzo de 2008.
El proyecto PostgreSQL contina haciendo lanzamientos principales anualmente y

lanzamientos menores de reparacin de bugs, todos disponibles bajo la licencia
PostgreSQL, y basados en contribuciones de proveedores comerciales, empresas
aportantes y programadores de cdigo abierto mayormente.
Caractersticas
Algunas de sus principales caractersticas son, entre otras:
Alta concurrencia
Mediante un sistema denominado MVCC (Acceso concurrente multiversin, por sus siglas
en ingls) PostgreSQL permite que mientras un proceso escribe en una tabla, otros
accedan a la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una visin
consistente de lo ltimo a lo que se le hizo commit. Esta estrategia es superior al uso de
bloqueos por tabla o por filas comn en otras bases, eliminando la necesidad del uso de
bloqueos explcitos...
Amplia variedad de tipos nativos
PostgreSQL provee nativamente soporte para:
Nmeros de precisin arbitraria.

Texto de largo ilimitado.
Figuras geomtricas (con una variedad de funciones asociadas).
Direcciones IP (IPv4 e IPv6).
Bloques de direcciones estilo CIDR.
Direcciones MAC.
Arrays.
Adicionalmente los usuarios pueden crear sus propios tipos de datos, los que pueden ser
por completo indexables gracias a la infraestructura GiST de PostgreSQL. Algunos
ejemplos son los tipos de datos GIS creados por el proyecto PostGIS.
Otras caractersticas
Claves ajenas tambin denominadas Llaves ajenas o Claves Forneas (foreign keys).
Disparadores (triggers): Un disparador o trigger se define como una accin especfica que
se realiza de acuerdo a un evento, cuando ste ocurra dentro de la base de datos. En
PostgreSQL esto significa la ejecucin de un procedimiento almacenado basado en una
determinada accin sobre una tabla especfica. Ahora todos los disparadores se definen
por seis caractersticas:
El nombre del disparador o trigger
El momento en que el disparador debe arrancar
El evento del disparador deber activarse sobre...
La tabla donde el disparador se activar
La frecuencia de la ejecucin
La funcin que podra ser llamada
La funcin no es correcta
Entonces combinando estas seis caractersticas, PostgreSQL le permitir crear una
amplia funcionalidad a travs de su sistema de activacin de disparadores (triggers).
Vistas.
Integridad transaccional.
Herencia de tablas.
Tipos de datos y operaciones geomtricas.
Soporte para transacciones distribuidas. Permite a PostgreSQL integrarse en un sistema
distribuido formado por varios recursos (p.ej, una base de datos PostgreSQL, otra Oracle,
una cola de mensajes IBM MQ JMS y un ERP SAP) gestionado por un servidor de
aplicaciones donde el xito ("commit") de la transaccin global es el resultado del xito de
las transacciones locales. Ms informacin en ingls en
http://www.theserverside.com/discussions/thread.tss?thread_id=21385#95297 y en
http://java.sun.com/javaee/technologies/jta/index.jsp.
Funciones
Bloques de cdigo que se ejecutan en el servidor. Pueden ser escritos en varios

lenguajes, con la potencia que cada uno de ellos da, desde las operaciones bsicas de
programacin, tales como bifurcaciones y bucles, hasta las complejidades de la
programacin orientada a objetos o la programacin funcional.
Los disparadores (triggers en ingls) son funciones enlazadas a operaciones sobre los
datos.
Algunos de los lenguajes que se pueden usar son los siguientes:
Un lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).

C.
C++.
Java PL/Java web.
PL/Perl.
plPHP.
PL/Python.
PL/Ruby.
PL/sh.
PL/Tcl.
PL/Scheme.
Lenguaje para aplicaciones estadsticas R por medio de PL/R.
PostgreSQL soporta funciones que retornan "filas", donde la salida puede tratarse como
un conjunto de valores que pueden ser tratados igual a una fila retornada por una consulta
(query en ingls).
Las funciones pueden ser definidas para ejecutarse con los derechos del usuario ejecutor
o con los derechos de un usuario previamente definido. El concepto de funciones, en
otros DBMS, son muchas veces referidas como "procedimientos almacenados" (stored
procedures en ingls).
Ventajas
-Seguridad en trminos generales
-Integridad en BD: restricciones en el dominio
-Integridad referencial
-Afirmaciones (Assertions)
-Disparadores (Triggers)
-Autorizaciones
-Conexin a DBMS
-Transacciones y respaldos
Productos alrededor de PostgreSQL

El PGDG solo desarrolla el Motor de Datos y un nmero pequeo de utilidades, para
potenciar el trabajo con PostgreSQL suele ser necesario aadir utilidades externas
creadas especialmente para este motor, algunas de estas herramientas son:
Historial de liberaciones
Primera ltima versin ltima ---
Liberacin
liberacin menor liberacin -
0.01 1995-05-01 0.03 1995-07-21
1.0 1995-09-05 1.09 1996-11-04
6.0 1997-01-29
6.1 1997-06-08 6.1.1 1997-07-22
6.2 1997-10-02 6.2.1 1997-10-17
6.3 1998-03-01 6.3.2 1998-04-07
6.4 1998-10-30 6.4.2 1998-12-20
6.5 1999-06-09 6.5.3 1999-10-13
7.0 2000-05-08 7.0.3 2000-11-11
7.1 2001-04-13 7.1.3 2001-08-15
7.2 2002-02-04 7.2.8 2005-05-09
7.3 2002-11-27 7.3.21 2008-01-07
7.4 2003-11-17 7.4.30 2010-10-04
8.0 2005-01-19 8.0.26 2010-10-04
8.1 2005-11-08 8.1.23 2010-12-16
8.2 2006-12-05 8.2.23 2011-09-26
8.3 2008-02-04 8.3.23 2013-02-07
8.4 2009-07-01 8.4.22 2014-07-24
9.0 2010-09-20 9.0.23 2015-10-08
9.1 2011-09-12 9.1.24 2016-10-27
9.2 2012-09-10 9.2.19 2016-10-27
9.3 2013-09-09 9.3.15 2016-10-27
9.4 2014-12-18 9.4.10 2016-10-27
9.5 2016-01-07 9.5.5 2016-10-27
9.6 2016-09-29 9.6.1 2016-10-27
Soportado por la comunidad
Sin soporte de la
comunidad2
Alternativas Comerciales
Gracias a su licencia BSD, se permite la utilizacin del cdigo para ser comercializado.
Uno de los casos ejemplo es la de Enterprise DB (Postgresql Plus), la cual incluye varios
agregados y una interfaz de desarrollo basada en Java. Entre otras empresas que utilizan
Postgresql para comercializar se encuentra CyberTech (Alemania), con su producto
CyberCluster.
GIS
PostGIS
Extensin que aade soporte de objetos geogrficos a PostgreSQL y permite realizar
anlisis mediante consultas SQL espaciales o mediante conexin a aplicaciones GIS
(Sistema de Informacin Geogrfica).
Replicacin
PgCluster
Replicacin multi maestro.
Slony-I
Replicacin maestro esclavo.
PyReplica
Replicacin maestro esclavo y multi maestro asincrnica.
Herramientas de administracin
PgAdmin3
Entorno de escritorio visual. Instalable en plataformas Linux, FreeBSD, Solaris, Mac OSX y
Windows. Permite conectarse a bases de datos PostgreSQL que estn ejecutndose en
cualquier plataforma.
Facilita la gestin y administracin de bases de datos ya sea mediante instrucciones SQL
o con ayuda de un entorno grfico. Permite acceder a todas las funcionalidades de la
base de datos; consulta, manipulacin y gestin de datos, incluso opciones avanzadas
como manipulacin del motor de replicacin Slony-I
PgAccess
Entorno de escritorio visual.
PhpPgAdmin
Entorno web.
psql
Cliente de consola.
Database Master
Entorno de escritorio visual.
Bsqueda de texto
Full text search

Incluido en el ncleo a partir de la versin 8.3.
Via Tsearch2 y OpenFTS para versiones anteriores a la 8.3.
XML
XML/XSLT soporte
Via XPath extensiones en la seccin contrib.
Usuarios destacados
.org, .info, .mobi y .aero registros de dominios por Afilias.3
La American Chemical Society.
BASF.
IMDb.
Skype.
TiVo.
Penny Arcade.
Sony Online.4
U.S. Departamento de Trabajo.
USPS.
VeriSign.
Pictiger.com
Wisconsin Circuit Court Access con 6 * 180GB DBs replicados en tiempo real.
OpenACS y .LRN.
INEGI.
IFE.
CartoCiudad.5 del IGN de Espaa.
Premios
PostgreSQL ha recibido los siguientes reconocimientos:6
1999 LinuxWorld Editor's Choice Award for Best Database

2000 Linux Journal Editors' Choice Awards for Best Database
2002 Linux New Media Editors Choice Award for Best Database
2004 Linux New Media Award For Best Database
2004 ArsTechnica Best Server Application Award
2008 Developer.com Product of the Year, Database Tool
PgAdmin III
pgAdmin III es una aplicacin grfica para gestionar PostgreSQL
pgAdmin III es una aplicacin grfica para gestionar el gestor de bases de datos PostgreSQL, siendo la ms
completa y popular con licencia Open Source. Est escrita en C++ usando la librera grfica multiplataforma
wxWidgets, lo que permite que se pueda usan en Linux, FreeBSD, Solaris, Mac OS X y Windows. Es capaz de gestionar
versiones a partir de la PostgreSQL 7.3 ejecutndose en cualquier plataforma, as como versiones comerciales
de PostgreSQL como Pervasive Postgres, EnterpriseDB, Mammoth Replicator y SRA PowerGres.
pgAdmin III est diseado para responder a las necesidades de todos los usuarios, desde escribir consultas SQL
simples hasta desarrollar bases de datos complejas. El interfaz grfico soporta todas las caractersticas de
PostgreSQL y facilita enormemente la administracin. La aplicacin tambin incluye un editor SQL con resaltado
de sintaxis, un editor de cdigo de la parte del servidor, un agente para lanzar scripts programados, soporte
para el motor de replicacin Slony-I y mucho ms. La conexin al servidor puede hacerse mediante conexin
TCP/IP o Unix Domain Sockets (en plataformas *nix), y puede encriptarse mediante SSL para mayor seguridad.
Contenido
[ocultar]
1 Instalacin
2 Actualizar a una versin ms moderna
2.1 Mtodo rpido
2.2 Mtodo compilado
3 Ver tambin
4 Enlaces externos
Instalacin
La versin 1.4.3 trae importantes mejoras
Dado que esta aplicacin se encuentra en los repositorios, tan slo tendremos que instalar el paquete
pgadmin3. En el men de aplicaciones no vers que se incluya una entrada para esta aplicacin. Esto es
debido a que hay un error en la elaboracin del paquete. Esto pasa con los paquetes Debian que no se han
adaptado a la poltica de mens de Ubuntu. Lee el artculo Activar el men Debian para ver como se activa el men
Debian y luego vers como aparece la entrada en Aplicaciones -> Debian -> Apps -> Databases.
Actualizar a una versin ms moderna

La versin de pgAdmin III que viene en los repositorios es algo antigua (la 1.2.2) y la aplicacin ya va por la
1.8.2, de modo que es buena idea ponerse un poco al da. Tienes dos opciones, o usas los paquetes que he
compilado yo o los compilas tu. Si has elegido el mtodo fcil, los paquetes estn en http://www.guia-
ubuntu.org/paquetes/.
En Egdy y Feisty ya viene la versin 1.4.3 en los repositorios, de modo que la puedes instalar fcilmente.
Mtodo rpido
La ltima versin de pgAdmin hasta el momento es la 1.8.2 la cual no compila en Ubuntu pero si que puedes
instalar una versin 1.8.0 compilada aadiendo este repositorio a la lista:
deb http://ftp5.es.postgresql.org/mirror/postgresql/pgadmin3/release/ubuntu gutsy pgadmin
Cambia gutsy por feisty o dapper segn sea el caso.
Los paquetes vienen firmados, por lo que debers aadir la clave pblica correspondiente:
$ wget -q -O - http://www.pgadmin.org/pgp/archive_key_debian_ubuntu.gpg | sudo apt-key add -
Mtodo compilado
Si has elegido el mtodo complicado, lo que haremos es compilar una Ubuntu el paquete de Debian de la ltima
versin.
1.- Eliminamos la versin de pgAdmin III que tenemos instalada:
$ sudo aptitude purge pgadmin3
2.- Aade el siguiente repositorio de fuentes (la puedes eliminar al final):

deb-src ftp://ftp.es.debian.org/debian unstable main
3.- Actualizamos la base de datos de los paquetes (dar un error de verificacin de clave PGP que puedes
ignorar):
$ sudo aptitude update
4.- Instalamos lo necesario para compilar:

$ sudo aptitude install build-essential
5.- Instalamos las dependencias necesarias para compilar el paquete:

$ sudo apt-get build-dep pgadmin3 pgadmin3-data
6.- Generamos los paquetes compilados para instalar a partir de los fuentes (tarda un rato):
$ sudo apt-get -b source pgadmin3 pgadmin3-data
7.- Instala los paquetes generados:

$ sudo dpkg -i pgadmin3_1.4.3-1_i386.deb pgadmin3-data_1.4.3-1_all.deb
8.- Eliminamos los ficheros intermedios

$ sudo rm -rf pgadmin3* pgagent*
Administracin y manual de PostgreSQL en Linux

Instalacin de PostgreSQL en CentOS
Conexin a un servidor PostgreSQL
Permitir conexiones remotas a PostgreSQL
Modificar la contrasea del usuario postgres de PostgreSQL
Comprobar la versin de PostgreSQL instalada
Backup y restore de bases de datos en PostgreSQL
Activar el modo de compatibilidad con versiones anteriores de PostgreSQL
Instalacin de PostgreSQL en un servidor con Plesk
Conexin a PostgreSQL desde PHP
Actualizar el formato/esquema de las bases de datos PostgreSQL
Instalacin de PostgreSQL en CentOS

Para utilizar el servidor de bases de datos PostgreSQL en CentOS es necesario instalar los
paquetes postgresql y postgresql-server:
yum install postgresql-server postgresql
Grab
El paquete postgresql-server contiene los binarios del servidor DBMS, y postgresql las
utilidades cliente para conectarnos a un servidor, as como documentacin en formato HTML y
las pginas "man".
El servicio no queda activado en el arranque, as que lo activaremos con la utilidad chkconfig:
# chkconfig postgresql on
# /etc/init.d/postgresql start
Iniciando la base de datos: [ OK ]
Iniciando servicios postgresql: [ OK ]
Grab
Conexin a un servidor PostgreSQL
Para conectarnos al servidor PostgreSQL nos cambiamos al usuario postgres y utilizamos el

CLI psql, ejemplo:
# su - postgres
$ psql -d template1 -U postgres

Welcome to psql 8.1.11, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
template1=#
Grab
Permitir conexiones remotas a PostgreSQL

Por seguridad, tras una instalacin por defecto de PostgreSQL en CentOS, este aceptar
nicamente conexiones locales en el puerto 5432/tcp:
# netstat -punta | grep LISTEN
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN

15112/postmaster
Grab
Para modificar este comportamiento tenemos que editar el fichero

/var/lib/pgsql/data/pg_hba.conf, que contiene la configuracin para la autenticacin de
clientes y aadir el listado de las redes y/o IPs desde las que nos vamos a conectar:
# vim /var/lib/pgsql/data/pg_hba.conf
host all all 192.168.0.0/24 trust
Grab
Adems, tenemos que editar el fichero /var/lib/pgsql/data/postgresql.conf y modificar el

parmetro listen_addresses para indicar que escuche en las interfaces necesarias, en este
caso lo habilitaremos para todas:
# vim /var/lib/pgsql/data/postgresql.conf
listen_addresses='*'
Grab
El ltimo paso es reiniciar el servicio y comprobar que los cambios se han aplicado
correctamente:
# /etc/init.d/postgresql restart
Parando el servicio postgresql: [ OK ]
Iniciando servicios postgresql: [ OK ]
# netstat -punta | grep LISTEN
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN

15608/postmaster
Grab
En este ejemplo, permitimos el acceso a la red 192.168.0.0/24 y a la IP 10.10.0.1, quedando

el servicio postmaster escuchando en todas las interfaces . Para mas informacin consultar el
captulo Client Authentication de la gua de Administracin de PostgreSQL.
Modificar la contrasea del usuario postgres de PostgreSQL

Para cambiar la contrasea de un usuario de PostgreSQL tenemos que utilizar la sentencia SQL
ALTER USER usuario WITH PASSWORD:
# su - postgres
template1=# ALTER USER postgres WITH PASSWORD 'zaQ6RzRhFb';
ALTER ROLE
Grab
Comprobar la versin de PostgreSQL instalada
La forma mas cmoda es ejecutando la sentencia SQL SELECT VERSION(), ejemplo:
template1=# SELECT VERSION();
version
--------------------------------------------------------------------------------------------
---------------
PostgreSQL 8.1.11 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red
Hat 4.1.2-14)
(1 fila)
Grab
Backup y restore de bases de datos en PostgreSQL
En PostgreSQL tenemos el comando pg_dump para realizar copias de seguridad de BBDD, su

uso es muy similar al mysqldump de MySQL. En este ejemplo obtenemos un listado de todas
las BBDD existentes y realizamos el backup de una de ellas:
$ LANG=en_US psql -l
List of databases
Name | Owner | Encoding
--------------+----------+----------
postgres | postgres | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
woop_pruebas | postgres | UTF8
(4 rows)
$ pg_dump woop_pruebas > /tmp/woop_pruebas.pg

Grab
El resultado es un fichero ASCII con todas las sentencias SQL necesarias para restaurar la
BBDD.
Para restaurar una BBDD desde un fichero utilizaremos el comando:
$ psql -d woop_pruebas -f /tmp/woop_pruebas.pg
SET
SET
SET
COMMENT
REVOKE
REVOKE
GRANT
GRANT
Grab
Para hacer un backup de todas las BBDD podemos utilizar el comando pg_dumpall o realizar
un pequeo script en BASH, ejemplo:
#!/bin/bash
DIR=/var/lib/pgsql/backups
LANG=en_US LIST=$(psql -l | awk '{ print $1}' | grep -vE '^-|^List|^Name|template[0|1]|^\(')
for db in $LIST
do
pg_dump $db | gzip -c > $DIR/$db.gz
done
Grab
Activar el modo de compatibilidad con versiones anteriores de PostgreSQL
Para habilitar la compatibilidad con versiones anteriores de PostgreSQL tenemos que editar el
fichero /var/lib/pgsql/data/postgresql.conf y aadir las siguientes variables (mas
informacin en el captulo Version and Platform Compatibility):
add_missing_from = on
array_nulls = on
backslash_quote = safe_encoding
default_with_oids = on
escape_string_warning = on
standard_conforming_strings = off
regex_flavor = advanced
sql_inheritance = on
Grab
add_missing_from: When on, tables that are referenced by a query will be

automatically added to the FROM clause if not already present. This behavior does not
comply with the SQL standard and many people dislike it because it can mask mistakes
(such as referencing a table where you should have referenced its alias). The default is
off. This variable can be enabled for compatibility with releases of PostgreSQL prior to
8.1, where this behavior was allowed by default.
array_nulls: This controls whether the array input parser recognizes unquoted
NULL as specifying a null array element. By default, this is on, allowing array values
containing null values to be entered. However, PostgreSQL versions before 8.2 did not
support null values in arrays, and therefore would treat NULL as specifying a normal
array element with the string value "NULL". For backwards compatibility with
applications that require the old behavior, this variable can be turned off.
backslash_quote: This controls whether a quote mark can be represented by \' in

a string literal. The preferred, SQL-standard way to represent a quote mark is by
doubling it ('') but PostgreSQL has historically also accepted \'. However, use of \'
creates security risks because in some client character set encodings, there are
multibyte characters in which the last byte is numerically equivalent to ASCII \. If
client-side code does escaping incorrectly then a SQL-injection attack is possible. This
risk can be prevented by making the server reject queries in which a quote mark
appears to be escaped by a backslash. The allowed values of backslash_quote are on
(allow \' always), off (reject always), and safe_encoding (allow only if client encoding
does not allow ASCII \ within a multibyte character). safe_encoding is the default
setting.
default_with_oids: This controls whether CREATE TABLE and CREATE TABLE AS
include an OID column in newly-created tables, if neither WITH OIDS nor WITHOUT
OIDS is specified. It also determines whether OIDs will be included in tables created by
SELECT INTO. In PostgreSQL 8.1 default_with_oids is off by default; in prior versions of
PostgreSQL, it was on by default.
escape_string_warning: When on, a warning is issued if a backslash (\) appears

in an ordinary string literal ('...' syntax) and standard_conforming_strings is off. The
default is on. Applications that wish to use backslash as escape should be modified to
use escape string syntax (E'...'), because the default behavior of ordinary strings will
change in a future release for SQL compatibility. This variable can be enabled to help
detect applications that will break.
standard_conforming_strings: This controls whether ordinary string literals ('...') treat

backslashes literally, as specified in the SQL standard. The default is currently off,
causing PostgreSQL to have its historical behavior of treating backslashes as escape
characters. The default will change to on in a future release to improve compatibility
with the standard. Applications can check this parameter to determine how string
literals will be processed. The presence of this parameter can also be taken as an
indication that the escape string syntax (E'...') is supported. Escape string syntax
should be used if an application desires backslashes to be treated as escape characters.
regex_flavor: The regular expression "flavor" can be set to advanced, extended, or

basic. The default is advanced. The extended setting might be useful for exact
backwards compatibility with pre-7.4 releases of PostgreSQL.
sql_inheritance: This controls the inheritance semantics. If turned off, subtables are
not included by various commands by default; basically an implied ONLY key word. This
was added for compatibility with releases prior to 7.1.
Podemos comprobar que el cambio de dichas variables de configuracin se ha realizado

correctamente con la siguiente consulta:
# su - postgres
-bash-3.2$ psql -d template1 -U postgres
template1=# SELECT name, setting FROM pg_settings ;
Grab
Si al aadir y/o modificar cualquier variable PostgreSQL no arranca tendremos que revisar el
fichero de log /var/lib/pgsql/pgstartup.log para encontrar cualquier warning/error del
tipo:
FATAL: unrecognized configuration parameter "array_nulls"
FATAL: parameter "standard_conforming_strings" cannot be changed
Grab
Instalacin de PostgreSQL en un servidor con Plesk
NOTA: Para poder gestionar bases de datos PostgreSQL desde Plesk se necesita comprar el addon
"Power Pack"!!
Una vez comprado el addon, el panel de control Plesk permite la gestin de bases de datos
PostgreSQL.
Podemos instalar PostgreSQL en Plesk de dos formas: 1) desde el interfaz web (Home ->
Updates -> PostgreSQL) y 2) desde una shell con el "autoinstaller":
# autoinstaller --select-release-current --install-component postgresql
Grab
El siguiente paso es activarlo en el inicio del servidor, arrancar el servicio y asignar una contrasea al
usuario administrador "postgres":
# chkconfig postgresql on
# su - postgres
template1=# ALTER USER postgres WITH PASSWORD 'password';
ALTER ROLE
Grab
Depus tenemos que entrar al interfaz web (Home -> Database Servers) y configurar el
usuario administrador "postgres" con su contrasea, a partir de aqu podremos gestionar
PostgreSQL desde el Plesk. Adems, se instala la herramienta de adminstracin web phpPgAdmin
para los clientes junto con una utilidad muy bsica pg_manage que permite parar, arrancar e
reinciar el servicio PostgreSQL.
Conexin a PostgreSQL desde PHP
Para conectarnos a PostgreSQL desde PHP necesitamos instalar el paquete php-pgsql, que
propociona las extensiones pdo_pgsql.so y pgsql.so:
# yum install php-pgsql
# /etc/init.d/httpd restart
Grab
En una instalacin de PostgreSQL sobre CentOS, el mtodo de autenticacin configurado por

defecto es "ident" (servicio que no est habilitado por defecto), por lo que al conectarnos
desde PHP obtendremos el siguiente error:
LOG: could not connect to Ident server at address "127.0.0.1", port 113: Connection refused
FATAL: Ident authentication failed for user "recover"
Grab
La solucin pasa por editar el fichero /var/lib/pgsql/data/pg_hba.conf y cambiar el

mtodo de autenticacin:
# vim /var/lib/pgsql/data/pg_hba.conf
(..)
#host all all 127.0.0.1/32 ident sameuser
host all all 127.0.0.1/32 md5
Grab
Actualizar el formato/esquema de las bases de datos PostgreSQL

Cuando actualizamos y/o cambiamos de versin un servidor PostgreSQL tenemos que
actualizar tambin el formato/esquema de las bases de datos. En PostgreSQL no existe una
herramienta similar al mysql_upgrade de MySQL que nos automatizara la tarea, por lo que
tenemos que realizar una serie de pasos:
1) Backup
2) Borrar/mover el contenido de $PGDATA y volver a inicializar con initdb el nuevo formato de
las bases de datos PostgreSQL
3) Restore
# /etc/init.d/postgresql stop
# su - postgres
$ pg_dump woop_pruebas > /tmp/woop_pruebas.pg
$ rm -rf $PGDATA
$ initdb
$ psql -d woop_pruebas -f /tmp/woop_pruebas.pg
Grab
Si tras actualizar una instacia de PostgreSQL no actualizamos el formato de las bases de datos
al arrancar nos encontraramos con este error:
An old version of the database format was found.
You need to upgrade the data format before using PostgreSQL.
See /usr/share/doc/postgresql-8.4.7/README.rpm-dist for more information.
1. Introduccin
2. Funcionamiento de la Arquitectura
3. Instalacin
4. Configuracin
5. Creacin y Manejo de Base de Datos PostgreSQL
6. PSQL
7. PGAdmin III
8. Seguridad
9. SQL
10. Respaldos y Recuperacin
11. Monitoreo y Estadsticas
12. Rutinas de Mantenimiento
13. Point-in Time Recovery
Introduccin
PostgreSQL es un sistema de gestin de bases de datos objeto-relacional, distribuido
bajo licencia BSD y con su cdigo fuente disponible libremente. Es el sistema de
gestin de bases de datos de cdigo abierto ms potente del mercado y en sus
ltimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la
estabilidad del sistema. Un fallo en uno de los procesos no afectar el resto y el sistema continuar
funcionando.
A continuacin teneis un grfico que ilustra de manera general los componentes ms importantes en un
sistema PostgreSQL.
Aplicacin cliente: Esta es la aplicacin cliente que utiliza PostgreSQL como administrador de
bases de datos. La conexin puede ocurrir via TCP/IP sockets locales.
Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado de escuchar
por un puerto/socket por conexiones entrantes de clientes. Tambien es el encargado de crear los
procesos hijos que se encargaran de autentificar estas peticiones, gestionar las consultas y
mandar los resultados a las aplicaciones clientes
Ficheros de configuracion: Los 3 ficheros principales de configuracin utilizados por PostgreSQL,
postgresql.conf, pg_hba.conf y pg_ident.conf
Procesos hijos postgres: Procesos hijos que se encargan de autentificar a los clientes, de
gestionar las consultas y mandar los resultados a las aplicaciones clientes
PostgreSQL share buffer cache: Memoria compartida usada por POstgreSQL para almacenar datos
en cach.
Write-Ahead Log (WAL): Componente del sistema encargado de asegurar la integridad de los
datos (recuperacin de tipo REDO)
Kernel disk buffer cache: Cach de disco del sistema operativo
Disco: Disco fsico donde se almacenan los datos y toda la informacin necesaria para que
PostgreSQL funcione
Caractersticas
La ltima serie de produccin es la 9.3. Sus caractersticas tcnicas la hacen una de las bases de datos
ms potentes y robustas del mercado. Su desarrollo comenzo hace ms de 16 aos, y durante este
tiempo, estabilidad, potencia, robustez, facilidad de administracin e implementacin de estndares han
sido las caractersticas que ms se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy
bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez a el
sistema.
A continuacin teneis algunas de las caractersticas ms importantes y soportadas por PostgreSQL:
Generales
Es una base de datos 100% ACID
Integridad referencial
Tablespaces
Nested transactions (savepoints)
Replicacin asincrnica/sincrnica / Streaming replication - Hot Standby
Two-phase commit
PITR - point in time recovery
Copias de seguridad en caliente (Online/hot backups)
Unicode
Juegos de caracteres internacionales
Regionalizacin por columna
Multi-Version Concurrency Control (MVCC)
Multiples mtodos de autentificacin
Acceso encriptado via SSL
Actualizacin in-situ integrada (pg_upgrade)
SE-postgres
Completa documentacin
Licencia BSD
Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X,
Solaris, Tru64) y Windows 32/64bit.
Programacin / Desarrollo
Funciones/procedimientos almacenados (stored procedures) en numerosos lenguajes de

programacion, entre otros PL/pgSQL (similar al PL/SQL de oracle), PL/Perl, PL/Python y PL/Tcl
Bloques annimos de cdigo de procedimientos (sentencias DO)
Numerosos tipos de datos y posibilidad de definir nuevos tipos. Adems de los tipos estndares
en cualquier base de datos, tenemos disponibles, entre otros, tipos geomtricos, de direcciones
de red, de cadenas binarias, UUID, XML, matrices, etc
Soporta el almacenamiento de objetos binarios grandes (grficos, videos, sonido, ...)
APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, PHP, Lisp, Scheme, Qt
y muchos otros.
SQL
SQL92,SQL99,SQL2003,SQL2008
Llaves primarias (primary keys) y forneas (foreign keys)
Check, Unique y Not null constraints
Restricciones de unicidad postergables (deferrable constraints)
Columnas auto-incrementales
Indices compuestos, nicos, parciales y funcionales en cualquiera de los metodos de
almacenamiento disponibles, B-tree, R-tree, hash GiST
Sub-selects
Consultas recursivas
Funciones 'Windows'
Joins
Vistas (views)
Disparadores (triggers) comunes, por columna, condicionales.
Reglas (Rules)
Herencia de tablas (Inheritance)
Eventos LISTEN/NOTIFY
Podeis consultar la lista completa en ingles de caractersticas disponibles en todas las versiones en la
direccin http://www.postgresql.org/about/featurematrix
Algunos de los limites de PostgreSQL son:
Lmite Valor
Mximo tamao base de dato Ilimitado (Depende de tu sistema de almacenamiento)
Mximo tamao de tabla 32 TB
Mximo tamao de fila 1.6 TB
Mximo tamao de campo 1 GB
Mximo numero de filas por tabla Ilimitado
Mximo numero de columnas por tabla 250 - 1600 (dependiendo del tipo)
Mximo numero de indices por tabla Ilimitado
Historia
El proyecto PostgreSQL tal y como lo conocemos hoy en dia empez en 1996, aunque las bases y el
trabajo en la que se asienta tienen sus comienzos en la decada de los 70. A continuacin teneis una corta
descripcin de la historia de PostgreSQL.
Ingres 1977-1985 - "El comienzo"
La dcada de los 70 fue una dcada de desarrollos y pruebas de nuevos conceptos en el nuevo mundo de
los gestores de bases de datos.
IBM habia estado trabajando desde 1973 con los primeros conceptos, ideas y teorias sobre bases de
datos relacionales. Su proyecto "System R" fue entre otras cosas la primera implementacin del lenguaje
SQL (Structured Query Language). Este proyecto, sus decisiones de diseo y muchos de los algoritmos
usados, influenciaron muchos de los sistemas de bases de datos relacionales que aparecieron
posteriormente.
Por aquel entonces un profesor de la Universidad de Berkeley, Michael Stonebraker, leyo unos artculos
publicados por IBM sobre "System R" que le hicieron interesarse en el tema. Utilizando el dinero de otro
proyecto que ya tenia asignado, Ingres (INteractive Graphics REtrieval System), Stonebraker empezo a
desarrollar sus ideas sobre bases de datos relacionales. Durante estos aos Ingres mantuvo su cdigo
fuente abierto y permanecio en gran medida similar en conceptos a "System R".
A principio de los 80, Ingres estuvo compitiendo con Oracle por el liderazgo en el mundo de bases de
datos relacionales y su cdigo e implementacin evolucionaron y fueron el origen de otras bases de datos
relacionales, entre ellas podemos citar a Informix, NonStop SQL y Sybase (Microsoft SQL Server fue una
versin licenciada de Sybase hasta su version 6.0).
Michael Stonebraker dejo la Universidad de Berkeley en 1982 para comercializar Ingres pero volvio a la
misma en 1985 con nuevas ideas.
Postgres 1986-1994 - Despues (post) de ingres
Despues de su vuelta a Berkeley en 1985, Michael Stonebraker lider un nuevo proyecto llamado
Postgres (despues de Ingres) patrocinado por la Defense Advanced Research Projects Agency (DARPA), la
Army Research Office (ARO), la National Science Foundation (NSF), y ESL, Inc. Con este proyecto y
basandose en la experiencia obtenida con Ingres, Stonebraker tenia como meta mejorar lo que habian
conseguido y aprendido en el desarrollo de Ingres. Y aunque se baso en muchas ideas de Ingres, no se
baso en el cdigo fuente del mismo.
Los objetivos iniciales de este proyecto fueron:
Proporcionar un mejor soporte para objetos complejos

Proporcionar a los usuarios la posibilidad de extender los tipos de datos, operadores y mtodos de
acceso.
Proporcionar los mecanismos necesarios para crear bases de datos activas (triggers, etc)
Simplificar el cdigo encargado de la recuperacin del sistema despues de una cada del mismo
Hacer cambios mnimos (preferiblemente ninguno) en el modelo relacional.
Mejorar el lenguaje de consulta QUEL heredado de Ingres (POSTQUEL).
Para los interesados en el tema, teneis disponibles una serie de artculos originales y completos en ingles
relacionados con el proyecto Postgres:
"The design of POSTGRES": El diseo de Postgres

"The POSTGRES data model": El mdelo de datos de Postgres
"The design of the POSTGRES storage system": El diseo del sistema de almacenamiento de Postgres
"The implementation of POSTGRES": Presentacin de la versin 1 de Postgres en la conferencia ACM-
SIGMOD de 1988
"A commentary on the POSTGRES rules system": Comentarios sobre el sistema de reglas de Postgres
"On Rules, Procedures, Caching and Views in Database Systems": Sobre reglas, procedimientos, cache y vistas
en sistemas de bases de datos
La ltima versin de Postgres en este projecto fue la versin 4.2.

Postgres95 1994-1995 - Nueva vida en el mundo opensource
En 1994, dos estudiantes de Berkeley, Andrew Yu y Jolly Chen, empezaron a trabajar con el cdigo de
Postgres (versin 4.2) y llamaron al proyecto Postgres95. Hicieron una limpieza general del cdigo,
arreglaron errores en el mismo, e implementaron otras mejoras, entre las que destacan:
Sustitucin de POSTQUEL por un interprete del lenguaje SQL

Reimplementacin de las funciones agregadas
psql fue creado para ejecutar consultas SQL
El interface de objetos grandes (large-object) fue revisado
Un pequeo tutorial sobre Postgres fue creado
Postgres se pudo empezar a compilar con GNU make y GCC sin parchear
La versin 1.0 de Postgre95 vio la luz en 1995, el cdigo era 100% ANSI C, un 25% ms corto en
relacin con la versin 4.2 y un 30-50% ms rpido. El cdigo fue publicado en la web y liberado bajo
una licencia BSD, y ms y ms personas empezaron a utilizar y a colaborar en el proyecto.
PostgreSQL 1996-actualidad - Proyecto PostgreSQL
En 1996, Andrew Yu y Jolly Chen ya no tenian tanto tiempo para dirigir y desarrollar Postgres95. Algunos
de los usuarios habituales de las listas de correo del proyecto decidieron hacerse cargo del mismo y
crearon el llamado "PostgreSQL Global Development Team".
En un principio este equipo de desarrolladores al cargo de la organizacin del proyecto estuvo formado
por Marc Fournier en Ontario, Canada, Thomas Lockhart en Pasadena, California, Vadim Mikheev en
Krasnoyarsk, Rusia y Bruce Momjian in Philadelphia, Pennsylvania. El nombre fue cambiado de
Postgres95 a PostgreSQL y lanzaron la versin 6.0 en enero de 1997.
Hoy en dia el grupo central (core team) de desarrolladores est formado por 6 personas, existen 38
desarrolladores principales y ms 21 desarrolladores habituales. En total alrededor de 65 personas
activas, contribuyendo con el desarrollo de PostgreSQL. Podeis encontrar ms informacin sobre este
equipo de desarrolladores en http://www.postgresql.org/community/contributors/
Existe tambien una gran comunidad de usuarios, programadores y administradores que colaboran
actvamente en numerosos aspectos y actividades relacionadas con el proyecto. Informes y soluciones de
problemas, tests, comprobacin del funcionamiento, aportaciones de nuevas ideas, discusiones sobre
caractersticas y problemas, documentacin y fomento de PostgreSQL son solo algunas de las actividades
que la comunidad de usuarios realiza.
No tenemos que olvidar tampoco que existen muchas empresas que tambien colaboran con dinero y/
con tiempo/personas en mejorar PostgreSQL. Muchos desarrolladores y nuevas caractersticas estn
muchas veces patrocinadas por empresas privadas.
En los ltimos aos los trabajos de desarrollo se han concentrado mucho en la velocidad de proceso y en
caractersticas demandadas en el mundo empresarial. En este grfico podeis ver cuando las diferentes
versiones de PostgreSQL han visto la luz y las principales caracteristicas en las que se ha centrado el
desarrollo.
Durante los aos de existencia del Proyecto PostgreSQL, el tamao del mismo, tanto en nmero de
desarrolladores, como en nmeros de linea de cdigo, funciones y complejidad del mismo ha ido
aumentando ao a ao. En el siguiente grfico teneis una grfica con la evolucin del nmero de lineas
de cdigo en cada versin de PostgreSQL.
Los datos de este grfico estan generados con CLOC. Contabilizamos como lineas de cdigo a todas las
lineas de cdigo en diferentes lenguaje, ms comentarios, menos lineas en blanco. Los ficheros HTML y
CSS no se cuentan como cdigo.
Usando el modelo de estimacin de costes de software "COCOMOII" (Constructive COst MOdel) podemos
obtener unos datos meramente orientativos pero que nos pueden ayudar a entender la complejidad del
proyecto PostgreSQL y los recursos que se necesitarian para desarrollar un producto similar desde cero.
Segn COCOMOII, obtendriamos estos nmeros para PostgreSQL 9.0.0:
Descripcin Valor
Nmeros de lineas de cdigo (PG-9.0.0) 969.562
Habilidad de los programadores (alta) 0,6
Complejidad del projecto (alta) 1,24
Precio/hora ($100.000/ao -
$53,3
1.875horas/ao)
Programadores-ao 618,71
Precio por linea de cdigo $65,30
Precio Total $63.316.697
Lineas de cdigo por persona/dia 7
Tiempo de desarrollo del proyecto (aos) 3.6
Nmero medio de programadores 171,4
Ref: http://www.cms4site.ru/utility.php?ecur=1.24&eafcur=0.6&utility=cocomoii...
Ciclo de vida (EOL) y soporte

El Proyecto PostgreSQL tiene como objetivo mantener y soportar cada versin de PostgreSQL durante 5
aos desde el momento de su lanzamiento. A continuacin teneis un resumen del ciclo de vida de las
diferentes versiones de PostgreSQL:
Versin Versin menor Soportada Lanzamiento Soporte

9.2 9.2.0 Si Sep 2012 Sep 2017
9.1 9.1.5 Si Sep 2011 Sep 2016
9.0 9.0.9 Si Sep 2010 Sep 2015
8.4 8.4.13 Si Jul 2009 Jul 2014
8.3 8.3.20 Si Feb 2008 Feb 2013
8.2 8.2.23 No Dic 2006 Dic 2011
8.1 8.1.23 No Nov 2005 Nov 2010
8.0 8.0.26 No Ene 2005 Oct 2010
7.4 7.4.30 No Nov 2003 Oct 2010
7.3 7.3.21 No Nov 2002 Nov 2007
7.2 7.2.8 No Feb 2002 Feb 2007
7.1 7.1.3 No Abr 2001 Abr 2006
7.0 7.0.3 No May 2000 May 2005
6.5 6.5.3 No Jun 1999 Jun 2004
6.4 6.4.2 No Oct 1998 Oct 2003
6.3 6.3.2 No Mar 1998 Mar 2003
4. Configuracin
Configuracin bsica de PostgreSQL

Dom, 29/03/2009 - 21:56 rafaelma
PostgreSQL se puede empezar a utilizar nada ms terminar de instalarlo y despues de

inicializar nuestro "cluster", sin necesidad de configurar nada. Pero si vamos a utilizar
PostgreSQL para algo importante y con cierto volumen de datos y usuarios es
imprescindible que lo configuremos para dicho trabajo.
No es la primera vez que algun asuario protesta o esta super preocupado de lo mal y lo
lento que funciona su cluster de base de datos PostgreSQL en un servidor ultimo modelo con muchisima
memoria. Normalmente el problema es que PostgreSQL no ha sido configurado para trabajar con el
volumen de datos y usuarios con el que lo estamos usando. No es una gran ayuda tener un servidor con
varios GBytes de memoria RAM si le hemos dicho a PostgreSQL, por ejemplo, que no utilice ms de
32MBytes.
Tambien tenemos que decir que cualquier base de datos que se este usando activamente, no solo
PostgreSQL, es un elemento dinamico y vivo en el que estamos cambiando los datos constantemente y
donde el tamao de los datos almacenados suele ir creciendo con el tiempo. Esto significa que una
configuracion que funcione bien con ciertos valores hoy, puede que no funcione tan bien despues de unos
meses de uso y que necesite ajustarse para que funcione optimalmente.
El comportamiento de PostgreSQL en nuestro sistema se puede controlar con tres ficheros de

configuracin que se encuentran en el directorio de datos donde inicializamos nuestro cluster PostgreSQL
(En nuestro caso /var/pgsql/data). Estos tres ficheros son:
pg_hba.conf: Este fichero se utiliza para definir los diferentes tipos de accesos que un usuario
tiene en el cluster.
pg_ident.conf: Este fichero se utiliza para definir la informacin necesaria en el caso que
utilicemos un acceso del tipo ident en pg_hba.conf .
postgresql.conf: En este fichero podemos cambiar todos los parametros de configuracion que
afectan al funcionamiento y al comportamiento de PostgreSQL en nuestra maquina.
Pasamos a continuacin a explicar los cambios mas importantes que podemos hacer en algunos de estos
ficheros.
pg_hba.conf
Este fichero se utiliza para definir como, donde y desde que sitio un usuario puede utilizar nuestro cluster
PostgreSQL. Todas las lineas que empiezen con el caracter # se interpretan como comentarios. El resto
debe de tener el siguiente formato:
[Tipo de conexion][database][usuario][IP][Netmask][Tipo de autentificacion][opciones]
Dependiendo del tipo de conexion y del tipo de autentificacion, [IP],[Netmask] y [opciones]pueden ser
opcionales. Vamos a explicar un poco como definir las reglas de acceso. El tipo de conexion puede tener
los siguientes valores, local, host, hostssl y hostnossl. El tipo de metodo puede tener los siguientes valores,
trust, reject, md5, crypt, password, krb5, ident, pam o ldap
Una serie de ejemplos nos ayudaran a comprender mejor como podemos configurar diferentes accesos al
cluster PostgreSQL.
Ejemplo 1 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el ordenador con
IP 10.0.0.100, y metodo de autentificacion md5:
host test001 test 10.0.0.100 255.255.255.255 md5
Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:
host test001 test 10.0.0.100/32 md5
Ejemplo 2 .- Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos los
ordenadores de la red 10.0.0.0, con mascara de red 255.255.255.0 (254 ordenadores en total) y metodo de
autentificacion md5:
host test001 test 10.0.0.0 255.255.255.0 md5
Esta misma entrada se podria escribir tambien con la mascara de red en notacion CIDR:
Ejemplo 3 .- Acceso por tcp/ip (red), encriptado, a todas las bases de datos de nuestro cluster, como
usuario test desde el ordenador con IP 10.0.0.100, y el ordenador 10.1.1.100 y metodo de autentificacion
md5 (necesitamos dos entradas en nuestro fichero pg_hba.conf:
hostssl all test 10.0.0.100 255.255.255.255 md5
Ejemplo 4.- Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde todos
los ordenadores de la red 10.0.0.0/24 y dar accesso al resto del mundo con el metodo md5:
host all test 10.0.0.0/24 reject
Asi podriamos seguir jugando con todas las posibilidades que nos brinda este fichero de configuracion.
Por supuesto que las bases de datos y usuarios usados en este fichero tienen que existir en nuestro
cluster para que todo funcione y algunos de los parametros solo se pueden usar si hemos compilado con
las opciones pertinentes en el proceso de instalacion (por ejemplo, hostssl, pam, krb5)
Para poder en produccion los cambios en este fichero tendremos que decirle a PostgreSQL que vuelva a
leerlo. Basta con un simple 'reload' (/usr/local/bin/pg_ctl -D /var/pgsql/data reload) desde la linea de comandos
o con la funcion pg_reload_conf() como usuario postgres desde psql, el cliente PostgreSQL.
[postgres@servidor]# /usr/local/bin/psql
Welcome to psql 8.2.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
postgres=# SELECT pg_reload_conf();
pg_reload_conf
----------------
(1 row)
postgres=#
Para una documentacion detallada sobre el fichero pg_hba.con, pasaros por la seccion Chapter 20. Client
Authentication de la documentacion oficial de PostgreSQL.
postgresql.conf
Los cambios que realicemos en este fichero afectaran a todas las bases de datos que tengamos definidas
en nuestro cluster PostgreSQL. La mayoria de los cambios se pueden poner en produccion con un simple
'reload' (/usr/local/bin/pg_ctl -D /var/pgsql/data reload), otros cambios necesitan que arranquemos de nuevo
nuestro cluster (/usr/local/bin/pg_ctl -D /var/pgsql/data restart ).
Mas informacion sobre todos los parametros que podemos cambiar en este fichero, que afectan y como
se pueden poner en produccion se puede encontrar en la seccion 17. Server Configuration de la
documentacion oficial de PostgreSQL.
A continuacion vamos a ver los parametros mas importantes que deberiamos cambiar si empezamos a
usar PostgreSQL para un uso serio y si queremos sacarle el maximo partido a nuestra maquina. Existen
muchos mas parametros que se pueden y con el tiempo se deberan de ajustar, aqui nos vamos a centrar
en los mas importantes y los cuales deberiamos cambiar antes de empezar a utilizar PostgreSQL de una
manera seria.
max_connections: Numero maximo de clientes conectados a la vez a nuestras bases de datos. Deberiamos
de incrementar este valor en proporcion al numero de clientes concurrentes en nuestro cluster
PostgreSQL. Un buen valor para empezar es el 100:
max_connections = 100
shared_buffers: Este parametro es importantisimo y define el tamao del buffer de memoria utilizado por
PostgreSQL. No por aumentar este valor mucho tendremos mejor respuesta. En un servidor dedicado
podemos empezar con un 25% del total de nuestra memoria. Nunca mas de 1/3 (33%) del total. Por
ejemplo, en un servidor con 4Gbytes de memoria, podemos usar 1024MB como valor inicial.
shared_buffers = 1024MB
work_mem: Usada en operaciones que contengan ORDER BY, DISTINCT, joins, .... En un servidor dedicado
podemos usar un 2-4% del total de nuestra memoria si tenemos solamente unas pocas sesiones
(clientes) grandes. Como valor inicial podemos usar 8 Mbytes.
work_mem = 8MB
maintenance_work_mem: Usada en operaciones del tipo VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE,
ADD FOREIGN KEY. Su valor dependera mucho del tamao de nuestras bases de datos. Por ejemplo, en
un servidor con 4Gbytes de memoria, podemos usar 256MB como valor inicial.
maintenance_work_mem = 256MB
effective_cache_size: Parametro usado por el 'query planner' de nuestro motor de bases de datos para
optimizar la lectura de datos. En un servidor dedicado podemos empezar con un 50% del total de nuestra
memoria. Como maximo unos 2/3 (66%) del total. Por ejemplo, en un servidor con 4Gbytes de memoria,
podemos usar 2048MB como valor inicial.
effective_cache_size = 2048MB
checkpoint_segments: Este parametro es muy importante en bases de datos con numerosas operaciones de
escritura (insert,update,delete). Para empezar podemos empezar con un valor de 64. En grandes
databases con muchos Gbytes de datos escritos podemos aumentar este valor hasta 128-256.
checkpoint_segments = 64
Es muy importante tener en cuenta que al aumentar los valores por defecto de muchos de estos
parametros, tendremos que aumentar los valores por defecto de algunos parametros del kernel de
nuestro sistema. Informacion detallada de como hacer esto se encuentra en la seccion 16.4. Managing Kernel
Resources de la documentacion oficial de PostgreSQL.
En fin, esto es solo un aperitivo de lo que podemos hacer. Con la practica y la experiencia podremos y
tendremos que ajustar otros muchos parametros. Pero esto sera materia de un proximo articulo.
Primeros pasos
Lo necesario para comenzar a utilizar PostgreSQL depender mucho de ciertos

factores. Estos factores se podrian resumir de la siguiente manera:
Experiencia: Tenemos alguna experiencia con otras bases de datos

relacionales? Estamos acostumbrados a la terminologia utilizada
conocemos algo de teoria de bases de datos relacionales?
Tipo de uso: Cmo vamos a utilizarla, en sistemas de produccin, para

desarrollar otros sistemas, para jugar y aprender SQL con ella?
Tamao del sistema: Cual es el tamao de las bases de datos que quereis administrar, las medis
en MB, GB, TB?
Carga del sistema: Cuantos usuarios van a utilizar el sistema y que concurrencia podemos
esperar?
Disponibilidad: Cuales son los requisitos de disponibilidad (uptime) de nuestro sistema?

Como podeis ver, son varios los factores a tener en cuenta para averiguar lo que necesitamos si
queremos utilizar PostgreSQL como nuestro sistema de gestion de bases de datos. Dependiendo de
nuestra experiencia, el tipo de uso, el tamao de los datos a gestionar, el numero de usuarios y requisitos
de disponibilidad, podremos tardar de solo unos cuantos minutos a varios dias/semanas en instalar un
sistema PostgreSQL que cubra nuestras necesidades.
Si simplemente quereis probar y "jugar" un poco con PostgreSQL, existen distribuciones binarias en casi
todas las distribuciones de Linux existentes y para sistemas Windows. Con cualquiera de estos paquetes
binarios podeis tener una instalacin bsica y lista para utilizar en cuestin de pocos minutos. Tambien
teneis por supuesto el cdigo fuente disponible y listo para ser compilado/instalado, si preferis este tipo
de instalacin. Pasaros por la seccin de descargas para obtener ms informacin sobre los productos
disponibles.
Si quereis utilizar PostgreSQL de una manera profesional y con sistemas en produccin deberiais
planificar vuestro sistema con ms detalle y aprender como podeis configurar PostgreSQL para sacarle el
mximo provecho. Es importante decir que una de las caracteristicas principales de PostgreSQL es su
facilidad de administracin comparada con muchos otros sistemas de gestin de bases de datos.
Probablemente tengais muchas preguntas, os aconsejo consultar Sobre PostgreSQL, 10 razones para utilizar
PostgreSQL y la seccin de documentacin del servidor. Si teneis alguna pregunta podeis utilizar los foros del
servidor utilizar cualquiera de los servicios disponibles (listas de correos / irc/ etc) en la seccin Comunidad
/ soporte
Instalacin de servidor de PostgreSQL y configuracin

Truco
Mtodos
El sitio de PostgreSQL lista el mtodo de instalacin disponible. Escoge la que mejor te provea.
Ejemplo en Ubuntu
Usa los siguientes comandos en tu terminal para instalar el paquete de postgresql:
sudo apt-get install postgresql
Por ejemplo:
openerp@openerp-desktop:/$ sudo apt-get install postgresql
Para una interfaz grfica de postgresql, usa el siguiente comando:
sudo apt-get install pgadmin3
Por ejemplo:
openerp@openerp-desktop:/$ sudo apt-get install pgadmin3
Puedes encontrar el nuevo elemento de pgAdmin III del men en tu sistema Ubuntu desde Aplicaciones
Programacin pgAdmin III.
Configura un usuario en PostgreSQL para OpenERP
Cuando la instalacin del software requerido este terminado, debers crear un usuario de PostgreSQL.
Este usuario deber ser el mismo que tu sistema de usuario. OpenERP usar este usuario para
conectarse a PostgreSQL.
Ilustracin demostrando como OpenERP hace uso del usuario de PostgreSQL e interactua con este
Truco
Base de datos
Como se explico antes, sin crear y configurar usuario de PostgreSQL para OpenERP, no podr crear
una base de datos usando el cliente OpenERP.
Primer mtodo
El super usuario predeterminado de PostgreSQL se llama postgres. Deber ingresar con este usuario
la primera vez.
openerp@openerp-desktop:/$ sudo su postgres
password: XXXXXXXXXX
Ahora crea el usuario de PostgreSQL openerp usando el siguiente comando:
postgres@openerp-desktop:/$ createuser openerp
Shall the new role be a superuser? (y/n) y
Make this new user a superuser. Only then you can create a database using OpenERP Client. In short,
openerp is the new user created in PostgreSQL for OpenERP. This user is the owner of all the tables
created by OpenERP Client.
Ahora checa la lista de tablas creadas en PostgreSQL usando los siguientes comandos:
postgres@openerp-desktop:/$ psql -l
Puede encontrar la tabla tempalte1, ejecuta el siguiente comando usando esta tabla:
postgres@openerp-desktop:/$ psql template1
Usa el siguiente comando para aplicar los permisos de acceso al rol openerp para que la base de
datos la cual ser creada desde el cliente de OpenERP:
template1=# alter role openerp with password 'postgres';
ALTER ROLE
Segundo mtodo
Otra opcin para crear y configurar un usuario en PostgreSQL para el OpenERP es mostrado a
continuacin:
postgres@openerp-desktop:/$ createuser --createdb --username postgres --no-

createrole
--pwprompt openerp
Enter password for new role: XXXXXXXXXX
Enter it again: XXXXXXXXXX
Shall the new role be a superuser? (y/n) y
CREATE ROLE
Nota
Contrasea
Nota que la contrasea es postgres.
Explicacin de opciones:
--createdb : el nuevo usuario ser capaz de crear una nueva base de

datos
--username postgres : createuser usar el usuario postgres (superuser)
--no-createrole : el nuevo usuario no ser capaz de crear nuevos
usuarios
--pwprompt : createuser requerir la nueva contrasea del usuario
openerp : el nuevo nombre del usuario
Deber configurar las conexiones de la siguiente forma para poder tener acceso va pgAdmin III:
MANUAL DE INSTALACIN DE PostgreSQL

PARA INSTALAR POSTGRESQL 9.2.3-1 EN WINDOWS SE DEBER CUMPLIR CON EL SIGUIENTE PROCEDIMIENTO:
1.- ACCEDER A UN EXPLORADOR DE INTERNET E INGRESAR LA SIGUIENTE DIRECCIN

www.postgresql.org/download/windows
2. PARA EL SIGUIENTE PASO HACER CLIC SOBRE DOWNLOAD. ESTO SER PARA DESCARGAR EL INSTALADOR
DEL PROGRAMA POSTGRESQL.
3.-SELECCIONAMOS EL MODO DE INSTALACIN.

4.- UNA VEZ DESCARGADO EL INSTALADOR, HACEMOS DOBLE CLIC SOBRE EL ICONO Y EMPEZAMOS LAS
INSTALACIN.
5.- SALDR UNA IMAGEN PARECIDA A ESTA:
6.- LUEGO APARECER LA SIGUIENTE VENTANA Y PRESIONAMOS SOBRE SIGUIENTE.

7.- NUEVAMENTE SE MOSTRARA UNA VENTANA EN DONDE PONDREMOS LA DIRECCIN O EL DIRECTORIO DE
INSTALACIN EN DONDE VAMOS A GUARDAR EL PROGRAMA.
8.- AHORA APARECER UNA NUEVA VENTANA, AQU PONDREMOS LA DIRECCIN DE DONDE VAMOS A
GUARDAR LOS DATOS.
9.- PULSAMOS NUEVAMENTE SIGUIENTE, AH TE APARECER UNA VENTANA EN LA QUE NOS PEDIR UNA
CONTRASEA DE USUARIO DE POSTGRESQL, INGRESAREMOS NUESTRA CONTRASEA.
10.- ENSEGUIDA APARECER UNA VENTANA EN LA QUE PEDIR EL PUERTO POR DONDE SE COMUNICARA EL
PROGRAMA, ESTE APARECER POR DEFAULT, ES EL PUERTO 5432, DEJAMOS EL MISMO NMERO DE PUERTO:
11.- AHORA TE PEDIR SI DESEAS CAMBIAR LA CONFIGURACIN REGIONAL, DEJAREMOS LA QUE DA POR
DEFAULT Y HAREMOS CLIC EN SIGUIENTE:
12.- AHORA APARECER UNA VENTANA EN LA CUAL INDICAR QUE EL PROGRAMA EST LISTO PARA
INSTALARSE. POSTERIOR A ESTO HAREMOS CLIC EN SIGUIENTE.
13.- NOS APARECER UNA VENTANA EN LA CUAL OBSERVAREMOS QUE SE EST INSTALANDO POSTRESQL.
14.- FINALMENTE FINIQUITAMOS LA INSTALACIN HACIENDO CLIC EN TERMINAR.
15.-PODEMOS IR AL PROGRAMA HACIENDO CLIC EN INICIO, TODOS LOS PROGRAMAS, BUSCAMOS POSTRESQL
Y POR ULTIMO HACEMOS CLIC EN PGADMINIII.
16.- EL PROGRAMA EST LISTO PARA USARSE.
17.- PARA PODER USAR Postgresql (CONECTAR CON EL SERVIDOR) DEBEMOS INTRODUCIR LA CONTRASEA
QUE NOSOTROS COMO USUARIOS ELEGIMOS DURANTE EL PROCESO DE LA INSTALACIN.
Ahora podr iniciar el servidor de OpenERP. Quizas deber modificar el archivo de configuracin de
OpenERP para sus necesidades las cuales estan normalmente ubicadas en el directorio ~/.openerprc
Instalacin de PostgreSQL en Debian GNU/Linux Wheezy
This entry was posted on 01/03/2013, in Base de datos, Distros GNU/Linux, GULMER, Linux,
Migracin, Software libre and tagged aptitude, Debian, gnu linux, GULMER, Linux, Migracin, PostgreSQL, Software
libre, Wheezy. Bookmark the permalink. 46 comentarios
Este articulo explica como instalar el servidor y un cliente de lineas de comandos de la base de datos
PostgreSQL en Debian Wheezy.
Introduccin
PostgreSQL
PostgreSQL, es un gestor de base de datos relacional, la primera versin del cdigo fue pblico el 1 de
agosto de 1996, liberado bajo la licencia BSD y desarrollado por PostgreSQL Global Development Group.
Debian GNU/Linux
Debian GNU/Linux, es un sistema operativo, liberado bajo la licencia GPL y desarrollado por Proyecto
Debian una comunidad de desarrolladores y usuarios.
Instalacin
Para este caso se instalara el servidor y un cliente de lineas de comandos PostgreSQL de la versin 9.1,
ejecutando el siguiente comando:
# aptitude install postgresql-9.1
Configuracin
Lo primero que se tiene que hacer es cambiarle la contrasea al usuario postgres que se crea luego de
haber instalado el paquete:
# passwd postgres
Acceda a la consola de administracin de PostgreSQL para cambiar la contrasea del usuario postgres
con los siguientes comandos:
# su postgres
postgres@nombre_maquina:/directorio$ psql postgres
postgres=# ALTER ROLE postgres PASSWORD 'CONTRASENA_DEL_USUARIO';
Donde postgres es el nombre del usuario al cual debe cambiar la contrasea

CONTRASENA_DEL_USUARIO por la que estableci previamente y luego salga de la sesin,
ejecutando los siguientes comandos:
postgres=# \q
postgres@nombre_maquina:/directorio$ exit
Configuracin de acceso local

Para dar acceso local, es decir, dar accesos a clientes PostgreSQL que estn en el mismo servidor donde
esta instalando el servidor PostgreSQL puede aplicar las siguientes configuraciones bsicas:
Debe que cambiar el archivo de configuracin del servidor PostgreSQL, con el siguiente
comando:
# vim /etc/postgresql/9.1/main/postgresql.conf
Busque la linea listen_addresses y verifique que su valor sea el siguiente:

listen_addresses = 'localhost'
Guarde el archivo y salga del editor.

Tambin debe modificar el archivo de configuracin del cliente PostgreSQL, con el siguiente
comando:
# vim /etc/postgresql/9.1/main/pg_hba.conf
En este archivo puede configurar los modos de autenticacin del cliente PostgreSQL y con que usuario
puede acceder a los datos almacenados en el servidor PostgreSQL.
Para este caso de configuracin usted esta conectndose localmente en el mismo servidor donde esta
instalado PostgreSQL por lo cual la IP local es 127.0.0.1, entonces agregue debajo de la linea # IPv4
local connections: la siguiente instruccin:
host nombre_base_datos usuario_postgresql 127.0.0.1/32 password
Donde nombre_base_datos y usuario_postgresql es el nombre de la base de datos y el usuario de

PostgreSQL a crear respectivamente mas adelante en este articulo.
Con estas configuraciones hechas debe reiniciar el servicio de PostgreSQL, con el siguiente comando:
# service postgresql restart
Configuracin de acceso remoto

Para dar acceso remoto a clientes PostgreSQL desde otro maquina o mascara de red distinta a la de donde
esta instalado servidor PostgreSQL puede aplicar las siguientes configuraciones bsicas:
Debe que cambiar el archivo de configuracin del servidor PostgreSQL, con el siguiente
comando:
# vim /etc/postgresql/9.1/main/postgresql.conf
Busque la linea listen_addresses = localhost y la cambia por el siguiente:

listen_addresses = '*'
Opcionalmente usted puede simplemente unir las direcciones IP especificas a la cual da acceso de la
siguiente forma:
listen_addresses='192.168.3.220 192.168.3.221'
Guarde el archivo y salga de la edicin.

Tambin debe modificar el archivo de configuracin del cliente PostgreSQL, con el siguiente
comando:
# vim /etc/postgresql/9.1/main/pg_hba.conf
En este archivo puede configurar desde que maquina o mascara de red puede acceder a los datos
almacenados en el servidor PostgreSQL y con que usuario se puede acceder.
Para ejemplo practico que se suponga que esta en una red 192.168.1.1/16 as que quiere darle acceso a
la IP 192.168.3.220, agregue debajo de la linea # IPv4 local connections: la siguiente instruccin:
host nombre_base_datos usuario_postgresql 192.168.2.3/32 md5
Donde nombre_base_datos y usuario_postgresql es el nombre de la base de datos y el usuario de

PostgreSQL a crear respectivamente mas adelante en este articulo.
El md5 es el mtodo de envi de la contrasea del usuario PostgreSQL por la red a comparacin de la
Configuracin de acceso local que se define en password la cual enva la contrasea en texto plano
por la red, en la Configuracin de acceso remota se configura md5 ya que enva contraseas
cifradas.
Con estas configuraciones hechas debe reiniciar el servicio del servidor PostgreSQL, con el siguiente
comando:
# service postgresql restart
Creando usuarios
Para crear usuarios vuelve a entrar como root de PostgreSQL para crear usuarios para conectarse a la base
de datos, en este caso usuario usuario_nomina con su contrasea 123456, con el siguiente comando:
# su postgres
postgres@nombre_maquina:/directorio$ createuser -D -S -R -l usuario_nomina
Este usuario usuario_nomina tiene permiso para no crear base de datos, no ser super usuario, no
crear roles de usuario, se le permite iniciar sesin respectivamente.
Para asignar la contrasea debe conectarse al servidor PostgreSQL, con el siguiente comando:
Esta la sesin conectado altere el usuario asignando una contrasea cifrada, con el siguiente comando:
postgres=# ALTER USER usuario_nomina WITH ENCRYPTED PASSWORD '123456';
ALTER ROLE
Para comprobar que el usuario se creo con xito, ejecute los siguientes comandos:
postgres=# SELECT usename, passwd FROM pg_shadow;
usename | passwd
----------------+-------------------------------------
postgres | md53175bce1d3201d16594cebf9d7eb3f9d
usuario_nomina | md5bad743050fa6b819130855f6cbb357ee
(2 filas)
Luego salga de la sesin de base de datos, ejecutando el siguiente comando:

postgres=# \q
Creando base de datos

Primero tiene que iniciar sesin como usuario root de PostgreSQL, con el siguiente comando:
# su postgres
Luego de iniciar sesin en el servidor como root, ahora usted puede crear una base de datos, con el
siguiente comando:
postgres@nombre_maquina:/directorio$ createdb -Ttemplate0 -O usuario_nomina
-EUTF-8 sistema_nomina
Esta base de datos sistema_nomina se basa en la plantilla de base de datos llamada template0 con la
cual es construida, el usuario dueo de la base de datos es el usuario usuario_nomina previamente
creado, usando el esquema de codificacin de caracteres UTF-8 soportado a ser usado en esta base de
datos respectivamente.
Para los privilegios del usuario usuario_nomina en la base de datos sistema_nomina debe
conectarse al servidor PostgreSQL, ejecute el siguiente comando:
Al estar en la sesin conectado otorgue todos los privilegios al usuario usuario_nomina en la base de
datos sistema_nomina, con el siguiente comando:
postgres=# GRANT ALL PRIVILEGES ON DATABASE sistema_nomina TO usuario_nomina;
Para comprobar que la base datos esta creada, ejecute el siguiente comando:
postgres=# SELECT datname FROM pg_database;
datname
-----------------
template0
postgres
template1
sistema_nomina
(4 filas)
Luego salga de la sesin de base de datos, ejecutando el siguiente comando:

postgres=# \q
Cargar estructura de datos y registros

A continuacin se crear una base de datos basado en un script que importa toda las sintaxis en lenguaje
de definicin de datos (DDL) y lenguaje de manipulacin de datos (DML) en SQL para construirla, ejecute el
siguiente comando:
postgres@nombre_maquina:/directorio$ psql -U postgres -f /home/macagua/script.sql
Luego salga de la sesin de usuario postgres, ejecutando el siguiente comando:
postgres@nombre_maquina:/directorio$ exit
Accediendo a la base de datos

Una ves realizado los pasos anteriormente descritos ahora puede conectarse con el usuario
usuario_nomina a la base de datos sistema_nomina y para estoy existe varias formas de acceso que
se describen a continuacin:
Acceso local a la base de datos
Se utiliza este forma de acceso a la base de datos cuando tiene hecha una configuracin de acceso local
y para esto se ejecuta el siguiente comando:
postgres@nombre_maquina:/directorio$ psql -d sistema_nomina -U usuario_nomina
Contrasea para usuario usuario_nomina:
psql (9.1.8)
Digite help para obtener ayuda.
sistema_nomina=> help
Est usando psql, la interfaz de lnea de rdenes de PostgreSQL.
Digite: \copyright para ver los trminos de distribucin
\h para ayuda de rdenes SQL
\? para ayuda de rdenes psql
\g o punto y coma (;) para ejecutar la consulta
\q para salir
sistema_nomina=>
Acceso remoto a la base de datos

Se utiliza este forma de acceso a la base de datos cuando tiene hecha una configuracin de acceso
remoto, a diferencia del acceso local a la base de datos en este caso tiene que indicar el host al cual
se desea conectar, para hacer esto se ejecuta el siguiente comando:
postgres@nombre_maquina:/directorio$ psql -h 10.10.29.50 -U usuario_nomina -d
sistema_nomina
Contrasea para usuario usuario_nomina:
psql (9.1.8)
Digite help para obtener ayuda.
sistema_nomina=> help
Est usando psql, la interfaz de lnea de rdenes de PostgreSQL.
Digite: \copyright para ver los trminos de distribucin
\h para ayuda de rdenes SQL
\? para ayuda de rdenes psql
\g o punto y coma (;) para ejecutar la consulta
\q para salir
sistema_nomina=>
Y as de esta forma esta listo para trabajar con la base de datos!

Seguridad
La seguridad de la base de datos esta implementada en varios niveles:
Proteccin de los ficheros de la base de datos. Todos los ficheros almacenados
en la base de datos estan protegidos contra escritura por cualquier cuenta que
no sea la del superusuario de Postgres.
Las conexiones de los clientes al servidor de la base de datos estan permitidas,
por defecto, nicamente mediante sockets Unix locales y no mendiante sockets
TCP/IP. Ha de arrancarse el demonio con la opcion -i para permitir la conexion
de clientes no locales.
Las conexiones de los clientes se pueden restringir por direccin IP y/o por
nombre de usuario mediante el fichero pg_hba.conf situado en PG_DATA.
Las conexiones de los clientes pueden ser autentificadas mediante otros
paquetes externos.
A cada usuario de Postgres se le asigna un nombre de usuario y
(opcionalmente) una contrasea. Por defecto, los usarios no tienen permiso de
escritura a bases de datos que no hayan creado.
Los usuarios pueden ser incluidos en grupos, y el acceso a las tablas puede
restringirse en base a esos grupos.
Autentificacion de Usuarios
Autentificacion es el proceso mediante el cual el servidor de la base de datos y el
postmaster se aseguran de que el usario que est solicitando acceso a la base de datos
es en realidad quien dice ser. Todos los usarios que quieren utilizar Postgres se
comprueban en la tabla pg_user para asegurarse que estn autorizados a hacerlo.
Actualmente, la verificacin de la identidad del usuario se realiza de distintas formas:
Desde la shell del usuario
Un demonio que se lanza desde la shell del usuario anota el id original del
usuario antes de realizar un setuid al id del usuario postgres. El id original del
usuario se emplea como base para todo tipo de comprobaciones.
Desde la red
Si Postgres se instala como distribuido, el acceso al puerto TCP del postmaster

est disponible para todo el mundo. El ABD configura el fichero pg_hba.conf
situado en el directorio PG_DATA especificando el sistema de autentificacion a
utilizar en base al equipo que realiza la conexin y la base de datos a la que se
conecta. Ver pg_hba.conf(5) para obtener una descripcin de los sistemas de
autentificacin disponibles. Por supuesto la autentificacin basada en equipos no
es perfecta incluso en los sistemas Unix. Es posible, para determinados intrusos,
enmascarar el equipo de origen. Estos temas de seguridad estn fuera del
alcance de Postgres.
Nombres de usuario y grupos

Para crear un nuevo usuario, ejecute el programa createuser.
Para aadir un usario o un grupo de usarios a un nuevo grupo uno de los usuarios
debe crear el grupo y aadir al resto a ese grupo. En Postgres estos pasos no pueden
realizarse actualmente mendiante el comando create group. Los grupos se definen
aadiendo los valores a la tabla pg_group, y usando el comando grant para asignar
privilegios al grupo.
Crear Usuarios
Crear Grupos
Actualmente no hay una forma facil de crear grupos de usuarios. Hay que
aadirlos/actualizarlos uno a uno en la tabla pg_group table. Por ejemplo: jolly=>
insert into pg_group (groname, grosysid, grolist) jolly=> values ('posthackers', '1234',
'{5443, 8261}'); INSERT 548224 jolly=> grant insert on foo to group posthackers;
CHANGE jolly=> Los campos de pg_group son: * groname: El nombre del grupo.
Este campo debe de ser unicamente alfanumrico. No aadas subrayados u otros
signos de puntuacin. * grosysid: El id del grupo. El tipo del campo es int4 y debe de
ser nico para cada grupo. * grolist: La lista de id de usarios que pertenecen al grupo.
Este campo es de tipo int4.
Asignar usuarios a los Grupos
Control de Acceso
Postgres proporciona mecanismos para permitir a los usuarios limitar el acceso que
otros usuarios tendrn a sus datos.
SuperUsuarios de la Base de Datos
Los SuperUsuarios de la base de datos (aquellos que tienen el campo

pg_user.usesuper activado) ignoran todos los controles de acceso descritos
anteriormente con dos excepciones: las actualizaciones del catlogo del sistema
no estn permitidas si el usuario no tiene el campo pg_user.usecatupd activado,
y nunca se permite la destruccin del catlogo del sistema (o la modificacin de
sus estructuras).
Privilegios de acceso
El uso de los privilegios de acceso para limitar la lectura, escritura y la puesta de

reglas a las clases se trata en grant/revoke(l).
Borrado de clases y modificacin de estructuras.
Los comandos que borran o modifican la estructura de una clase, como alter,
drop table, y drop index, solo funcionan con el propietario de la clase. Como
hemos dicho antes, estas operaciones no estn permitidas nunca en los catlogos
del systema.
Siguiente
Funciones y Reglas
Las funciones y las reglas permiten a los usuarios insertar cdigo en el servidor de la
base de datos que otros usuarios pueden ejecutar sin saberlo. Ambos mecanismos
permiten a los usuarios alojar caballos de troya con relativa impunidad. La nica
proteccin efectiva es un estrecho control sobre quien puede definir funciones (por
ejemplo, escribir en tablas con campos SQL) y reglas. Tambin se recomienda auditar
seguimientos y alertas en pg_class, pg_user y pg_group.
Funciones
Las funciones escritas en cualquier lenguaje excepto SQL se ejecutan por el servidor
de la base de datos con el mismo permiso que el usuario postgres (el servidor de la
base de datos funciona con el user-id de postgres. Es posible cambiar las estructuras
de datos internas del servidor por los usuarios, desde dentro de funciones de
confianza. Es por ello que este tipo de funciones pueden, entre otras cosas, evitar
cualquier sistema de control de acceso. Este es un problema inherente a las funciones
definidas por los usuarios en C.
Reglas
Como en las funciones SQL, las reglas tamben se ejecutan con la identidad y los
permisos del usuario que llam al servidor de la base de datos.
Caveats
There are no plans to explicitly support encrypted data inside of Postgres (though
there is nothing to prevent users from encrypting data within user-defined functions).
There are no plans to explicitly support encrypted network connections, either,
pending a total rewrite of the frontend/backend protocol.
User names, group names and associated system identifiers (e.g., the contents of
pg_user.usesysid) are assumed to be unique throughout a database. Unpredictable
results may occur if they are not.
Siguiente
Agregar y Eliminar Usuarios

createuser permite que usuarios especficos accedan a Postgres. dropuser elimina
usuarios y previene que stos accedan a Postgres.
Estas rdenes slo afectan a los usuarios con respecto a Postgres; no tienen efecto en
otros privilegios del usuario o en su estado con respecto al sistema operativo
subyacente.
Gestin de Disco
Localizaciones Alternativas
Se puede crear una base de datos en una localizacin diferente a la establecida por
defecto durante la instalacin. Recuerde que todos los accesos a base de datos
ocurren realmente a traves del proceso en segundo plano, as que ste debe poder
acceder a cualquier especificacin.
Se crean localizacines alternativas y referencias mediante una variable de entorno
que da el path absoluto hasta la situacin de almacenamiento deseada. Esta variable
de entorno debe estar definida antes de que el proceso en segundo plano sea
arrancado y debe ser modificable mediante la cuenta del administrador de postgres.
Cualquier variable de entorno puede ser utilizada para referirse a una localizacin
alternativa, si bien se recomienda la utilizacin de un nombre de variable con prefijo
PGDATA para evitar confusin y conflicto con otras variables.
En versiones previas de Postgres, tambin estaba permitido utilizar un nombre de
path absoluto para especificar una localizacin de almacenamiento alternativa. Se
prefiere el mtodo de especificacin de variables de entorno, puesto que concede al
administrador del sistema ms flexibilidad en la gestin del almacenamiento en
disco. Si prefiere utilizar paths absolutos, puede hacerlo definiendo
"ALLOW_ABSOLUTE_DBPATHS" y recompilando Postgres. Para hacer esto,
aada cualquiera de estas lneas
#define ALLOW_ABSOLUTE_DBPATHS 1
al archivo src/include/config.h, o especifique

CFLAGS+= -DALLOW_ABSOLUTE_DBPATHS
en su Makefile.custom.
Recuerde que la creacin de una base de datos la ejecuta realmente un proceso de la

base de datos en segundo plano. Por lo tanto, cualquier variable de entorno que
especifique una localizacin alternativa debe ser definida antes de que el proceso en
segundo plano sea arrancado. Para definir una localizacin alternativa apuntando a
PGDATA2 /home/postgres/data, primero escriba
% setenv PGDATA2 /home/postgres/data
para definir la variable de entorno que ser utilizada con las rdenes siguientes.
Normalmente, querr definir esta variable en el fichero de inicializacin del super
usuario de Postgres, .profile o .cshrc para asegurar que est definido al arrancar el
sistema. Se puede utilizar cualquier variable de entorno para referirse a una
localizacin alternativa, aunque se prefiere que las variables estn prefijadas con
"PGDATA" para eliminar confusiones y la posibilidad de conflictos con otras
variables, o su reescritura.
Para crear un area de almacenamiento de datos en PGDATA2, asegrese de que
/home/postgres ya existe y puede ser escrito por el administrador de postgres.
Despus desde la linea de rdenes, escriba
% setenv PGDATA2 /home/postgres/data
% initlocation $PGDATA2
Creating Postgres database system directory /home/postgres/data
Creating Postgres database system directory /home/postgres/data/base
Para comprobar la nueva localizacin, cree una base de datos test escribiendo
% createdb -D PGDATA2 test
% dropdb test
Gestin de una base de datos

Si el programa postmaster de Postgres est cargado y en ejecucin, podemos crear
algunas bases de datos con las que experimentar. En este documento describiremos
las rdenes bsicos para gestionar una base de datos.
Creacin de una base de datos

Supongamos que quiere crear una base de datos llamada mibase. Puede hacerlo con
el siguiente orden:
% createdb nombredb
Postgres le permite crear cualquier nmero de bases de datos en una mquina dada, y
usted se convierte automticamente en el administrador de la base de datos que acaba
de crear. Los nombres de las bases de datos han de comenzar por un caracter
alfabtico, y su longitud est limitada a 31 caracteres. No todos los usuarios estn
autorizados para convertirse en administradores de bases de datos. Si Postgres
rechaza la orden de crear bases de datos, es que necesita que el administrador del
sistema le garantice derechos para crear las bases de datos. Consulte a su
administrador de sistemas si le ocurre eso.
Gestin de una base de datos Siguiente
Acceso a la base de datos

Una vez que ha construido la base de datos, puede acceder a ella por los siguientes
medios:
Ejecutando el programa monitor de terminal de Postgres (psql) que le permite
introducir, editar y ejecutar rdenes SQL de un modo interactivo.
Escribiendo un programa en C que use la biblioteca de rutinas libpq. Esto le
permite enviar rdenes SQL desde C y obtener las respuestas y mensajes de
estado en su programa. Esta interfaz se discute en el documento Gua de
programacin en PostgreSQL.
Puede que quiera ejecutar el programa psql, para probar los ejemplos de este manual.
Puede activarlo para la base de datos nombredb escribiendo la orden:
% psql nombredb
Recibir como respuesta el siguiente mensaje:

Welcome to the Postgres interactive sql monitor:
type \? for help on slash commands

type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: nombredb
nombredb=>
Este indicativo le informa de que el monitor de terminal se encuentra dispuesto y que

puede escribir consultas SQL en el espacio de trabajo creado por el citado monitor de
terminal. El programa psqlresponde a cdigos de escape que comienzan con la barra
invertida, "\". Por ejemplo, puede obtener ayuda sobre la sintaxis de varias rdenes
SQL de Postgres escribiendo:
nombredb=> \h
Una vez que ha terminado de introducir sus consultas en el espacio de trabajo, puede
pasar el contenido de ste al servidor de Postgres escribiendo:
nombredb=> \g
Esto le dice al servidor que procese la consulta. Si termina su consulta con punto y
coma, no es necesario que introduzca la secuencia \g. psql procesar automticamente
consultas terminadas en punto y coma. Para leer las consultas de un fichero, en lugar
de introducirlas interactivamente, escriba:
nombredb=> \i fichero
Para salir de psql y volver a Unix, escriba:

nombredb=> \q
y psql terminar y le devolver el intrprete de rdenes. (Para conocer ms rdenes

de escape, escriba \h en la entrada del monitor.) Los espacios en blanco (espacios,
tabuladores y saltos de lnea) pueden usarse libremente en las consultas SQL. Los
comentarios en una sola lnea se indican mediante dos guiones ("--"). Todo lo que
vaya desde los guiones hasta el fin de la lnea ser ignorado. Los comentarios que
abarcan mltiples lneas, o que estn dentro de una lnea se encierran entre "/* ... */",
una convencin que se tom prestada de Ingres.
Copia de seguridad y restauracin

Deben realizarse copias de seguridad de las bases de datos regularmente. Dado que
Postgres gestiona sus propios ficheros en el sistema, no se recomienda confiar en los
sistemas de copia de seguridad del sistema para las copias de respaldo de las bases de
datos; no hay garanta de que los ficheros estn en un estado consistente que permita
su uso despus de la restauracin.
Postgres proporciona dos utilidades para realizar las copias de seguridad de su

sistema: pg_dump para copias de seguridad de bases de datos individuales y
pg_dumpall para realizar copias de seguridad de toda la instalacin de una sola vez.
La copia de seguridad de una sola base de datos puede realizarse usando la siguiente
orden:
% pg_dump nombredb > nombredb.pgdump
y puede ser restaurada usando

cat nombredb.pgdump | psql nombredb
Esta tcnica puede usarse para mover bases de datos a una nueva localizacin y para
renombrar bases de datos existentes..
Bases de datos grandes
Autor
Escrito por Hannu Krosing on 1999-06-19.
Dado que Postgres permite tablas de mayor tamao que el permitido por el sistema de
ficheros, puede resultar problemtico el volcado de una tabla a un fichero, ya que el
fichero resultante seguramente superar el tamao mximo permitido.
Como pg_dump escribe en stdout, puede usar las herramientas *nix para sortear estos
posibles problemas:
Uso de volcados comprimidos:
% pg_dump nombredb | gzip > nombrefichero.dump.gz
la recuperamos con:
% createdb nombredb
% gunzip -c nombrefichero.dump.gz | psql nombredb
o
% cat nombrefichero.dump.gz | gunzip | psql nombredb
Use split:
% pg_dump nombredb | split -b 1m - nombrefichero.dump.
y lo recuperamos con:
% createdb nombredb
% cat nombrefichero.dump.* | pgsql nombredb
Por supuesto, el nombre del fichero (nombrefichero) y el contenido de la salida de

pg_dump no tiene por qu coincidir con el nombre de la base de datos. Adems, la
base de datos restaurada puede tener un nombre distinto, por lo que este mecanismo
tambin es efectivo para renombrar bases de datos.
Tratamiento de problemas
Fallos de inicio de Postmaster

Hay varias posibles razones para que postmaster no pueda inicializarse. Compruebe
el fichero de registro de postmaster, o incielo manualmente (sin redirigir la salida
estndar o la de errores) para ver los mensajes que aparecen. Alguno de los posibles
mensajes de error son autoexplicativos, pero los hay que pueden no serlos tanto:
FATAL: StreamServerPort: bind() failed: Address already in use
Is another postmaster already running on that port?
Esto normalmente significa lo que sugiere: accidentalmente ha iniciado una segunda

instancia de postmaster en el mismo puerto en el que ya se est ejecutando uno. Sin
embargo, si el mensaje de error del ncleo no es "Address already in use" o alguna
variante, puede estar ocurriendo otro problema. Por ejemplo, el tratar de iniciar una
sesin de postmaster en un puerto de error reservado puede producir algo como:
$ postmaster -i -p 666
FATAL: StreamServerPort: bind() failed: Permission denied
Is another postmaster already running on that port?
IpcMemoryCreate: shmget failed (Invalid argument) key=5440001, size=83918612, permission=6

FATAL 1: ShmemCreate: cannot create region
Un mensaje como ste posiblemente indica que el limite impuesto al tamao de las
zonas de memoria compartidas es menor que rea de buffer que Postgres est
intentando crear. (O puede significar que no dispone de soporte para la memoria
compartida de tipo SysV configurado en su ncleo.) Como arreglo temporal puede
tratar de iniciar postmaster con un nmero de buffers menor de lo normal
(parmetro -B). Sin embargo, debera reconfigurar su ncleo para incrementar el
tamao permitido para la memoria compartida. Este mensaje puede aparecer cuando
trate de iniciar varias sesiones de postmaster en la misma mquina, si el total de
espacio necesario excede el lmite impuesto por el ncleo.
IpcSemaphoreCreate: semget failed (No space left on device) key=5440026, num=16, permissio
Un mensaje como ste no significa que se haya quedado sin espacio en el disco;
significa que la cantidad mxima de semforos permitidos por el ncleo para el SysV
es menor que la cantidad que Postgres intenta crear. Como antes, puede evitar este
problema iniciando el postmaster con un numero de procesos backend menor
(parmetro -N), pero sera mejor que incrementara el lmite impuesto por el ncleo.
Problemas con la conexin del Cliente

Una vez que tiene el postmaster en ejecucin, al tratar de conectar con l mediante
una aplicacin cliente puede producirse un fallo por varias razones. Los ejemplos de
mensajes de error mostrados aqu son para clientes basados en las versiones recientes
de libpq; los clientes basados en otras bibliotecas de interfaz pueden producir otros
mensajes, con ms o menos informacin.
connectDB() -- connect() failed: Connection refused
Is the postmaster running (with -i) at 'server.joe.com' and accepting connections on TCP/I
Este el es fallo genrico de 'No puedo encontrar un postmaster con el que
comunicarme'. Puede ocurrir algo as cuando se intenta una comunicacin TCP/IP o
mediante socket Unix con un postmaster local:
connectDB() -- connect() failed: No such file or directory
Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'?
La ltima lnea es til para verificar que el cliente est tratando de conectar donde se
supone que debe hacerlo. Si en realidad no hay ningn postmaster ejecutndose all,
el mensaje de error del ncleo ser del tipo de 'Conexin rehusada' o de 'No existe el
fichero o directorio', como los anteriores. (Es particularmente importante tener en
cuenta que 'Conexin rehusada' en este contexto no no significa que el postmaster
haya recibido la peticin de conexin y la haya rechazado; en este caso se produce un
mensaje diferente, como se ver.) Otros mensajes de error, como el de "Connection
timed out" s indican problemas ms importantes, como la falta de conectividad en la
red.
No pg_hba.conf entry for host 123.123.123.123, user joeblow, database testdb
Esto es lo ms probable que obtenga si consigue contactar con un postmaster, pero

ste no quiere hablar con usted. Como sugiere el mensaje, el postmaster rehsa la
peticin de conexin porque no encuentra un rengln de autorizacin en su fichero de
configuracin pg_hba.conf
Password authentication failed for user 'joeblow'
Los mensajes como ste indican que ha contactado con el postmaster, y ste est
dispuesto a hablar con usted, pero no lo har hasta que supere el mtodo de
autorizacin especificado en el fichero pg_hba.conf. Compruebe la clave que est
enviando, o su programa IDENT o Kerberos, si el mensaje de error menciona alguno
de esos tipos de autenticacin.
FATAL 1: SetUserId: user 'joeblow' is not in 'pg_shadow'
Esta es otra variante de fallo de autenticacin: no se ha ejecutado la orden de Postgres

'create_user' para el nombre de usuario indicado.
FATAL 1: Database testdb does not exist in pg_database
No hay base de datos con ese nombre bajo el control de ese postmaster. Ntese que si
no especifica el nombre de la base de datos, se aplica por defecto su nombre de
usuario en Postgres, lo que puede no ser lo correcto.
epuracin de mensajes
El postmaster presenta ocasionalmente mensajes que pueden ser de ayuda en la
solucin de problemas. Si desea ver mensajes de depuracin de postmaster, puede
iniciarlo con la opcin -d y redirigir la salida a un fichero de registro:
% postmaster -d > pm.log 2>&1 &
Si no desea ver estos mensajes, puede escribir

% postmaster -S
y el postmaster entrar en modo 'S'ilencioso. Ntese que no se incluye el simbolo '&'

en el ltimo ejemplo, ya que el postmaster se ejecutar en segundo plano.
pg_options
Contribucin de Massimo Dal Zotto
El fichero opcional data/pg_options contiene opciones de ejecucin usadas por el

backend para controlar mensajes de ejecucin y otros parmetros ajustables. Lo que
hace interesante a este fichero es el hecho de que es reledo por el backend cuando
recibe una seal SIGHUP, haciendo as posible cambiar opciones de ejecucin sin
tener que reiniciar Postgres. Las opciones especificadas en este fichero pueden incluir
puntos de depuracin usados por el paquete trace (backend/utils/misc/trace.c) o
parmetro numricos que puede usar el backend para controlar su comportamiento.
Se pueden definir nuevas opciones y parmetros en backend/utils/misc/trace.c y en
backend/include/utils/trace.h.
Las opciones de pg_option pueden especificarse con el parmetro -T de Postgres:
postgres opciones -T "verbose=2,query,hostlookup-"
Las funciones usadas para imprimir errores y mensajes de depuracin pueden ahora
usar la utilidad syslog(2). Los mensajes impresos en stdout o stderr son precedidos
por una etiqueta informativa que incluye la fecha y hora y el pid del backend:
#timestamp #pid #message
980127.17:52:14.173 [29271] StartTransactionCommand
980127.17:52:14.174 [29271] ProcessUtility: drop table t;
980127.17:52:14.186 [29271] SIIncNumEntries: table is 70% full
980127.17:52:14.186 [29286] Async_NotifyHandler
980127.17:52:14.186 [29286] Waking up sleeping backend process
980127.19:52:14.292 [29286] Async_NotifyFrontEnd
980127.19:52:14.413 [29286] Async_NotifyFrontEnd done
980127.19:52:14.466 [29286] Async_NotifyHandler done
Este formato mejora la legibilidad de los registros, y permite comprender qu

backend concreto est haciendo qu y en qu momento. Tambin hace ms fcil
escribir guiones (scripts) en awk o perl que monitoricen el fichero de registro para
detectar errores o problemas en la base de datos, o para contabilizar estadsticas
temporales de las transacciones.
Los mensajes impresos por syslog usan la utilidad de registro LOG_LOCAL0. El uso
de syslog puede ser controlado por las opciones referentes a l en syslog.
Desgraciadamente, muchas funciones llaman directamente a printf() para mostrar sus
mensajes en stdout o stderr y esta salida no puede ser redirigida a syslog o incluir
informacin sobre fecha y hora. Sera aconsejable que todas las llamadas a printf
pudieran ser reemplazadas por la macro PRINTF y la salida a stderr se cambiaran
para que usaran EPRINTF en su lugar, de modo que se pudieran controlar todas las
salidas de un modo uniforme.
El formato del fichero pg_options es como sigue:
# comentario
opcin=valor_entero # set value for opcin
opcin # set opcin = 1
opcin+ # set opcin = 1
opcin- # set opcin = 0
Ntese que palabra_clave puede ser tambin una abreviacin del nombre de opcin
definido en backend/utils/misc/trace.c.
Vase Usando pg_options para una lista completa de las opciones y sus posible
valores.
Pruebas de regresin
Instruciones y anlisis del test de regresin
Los tests de regresin de PostgreSQL son un conjunto completo de pruebas para la

implementacin de SQL embebidos en PostgreSQL. Realizan pruebas tanto sobre
operaciones SQL estndar, como tambin sobre las capacidades aadidas por
PostgreSQL.
Los tests de regresin fueron desarrollados originalmente por Jolly Chen y Andrew
Yu, y fueron extensamente repasados/reempaquetados por Fournier y Thomas
Lockhart. Para PostgreSQL v6.1 en adelante los tests de regresin forman parte de
cada release oficial.
Algunas bases de datos PostgreSQL correctamente instaladas y totalmente
funcionales pueden fallar en alguno de estos test de regresin debido a problemas con
la representacin del punto flotante y el soporte de zona horaria. Los tests actuales
son evaluados usando un sencillo algoritmo "diff", y son muy sensibles a pequeas
diferencias en el sistema. Para tests aparentemente fallidos, si se examinan estas
diferencias, pueden revelar no ser significativas.
Las notas sobre tests de regresin de abajo asumen lo siguiente (excepto en casos
indicados):
Las instrucciones son compatibles con Unix. Vea la nota abajo.
Se usan las opciones por defecto excepto donde se indica.
El usuario postgres es el superusuario Postgres.
La ruta de las fuentes es /usr/src/pgsql (son posibles otras rutas).
La ruta de los ejecutables es /usr/local/pgsql (son posibles otras rutas).
Entorno de regresin
Para preparar los tests de regresin, haga make all en el directorio de los tests de
regresin. Esto compila un programa C con funciones extendidas PostgreSQL en un
librera compartida. Se generan algunos guiones (scripts) SQL localizados y archivos
de salida comparativos para los tests que los necesiten. La localizacin reemplaza
macros en los archivos de fuentes con rutas absolutas y nombres de usuario.
Normalmente, los tests de regresin deben ser ejecutados por el usuario postgres ya
que el directorio 'src/test/regress' y subdirectorios son de su propiedad. Si ejecuta los
test de regresin con otro usuario el directorio 'src/test/regress' debe tener permisos de
escritura para ese usuario.
Antes era estrictamente necesario ejecutar el postmaster con la zona horaria del
sistema establecida en PST, pero ya no es necesario. Puede ejecutar los tests de
regresin sobre su configuracin habitual del postmaster. El guin (script) del test
establecer la variable de entorno PGTZ para asegurar que los tests dependientes de
la zona horaria produzcan los resultados esperados. De todas formas, su sistema debe
proporcionar libreras de soporte para la zona horaria PST8PDT, o los tests
dependientes de la zona horaria fallarn. Para comprobar que su equipo soporta esto,
escriba lo siguiente:
setenv TZ PST8PDT
date
La orden "date" de arriba tiene que devolver la hora actual del sistema en la zona
horaria PST8PDT. Si la base de datos PST8PDT no est disponible, entonces el
sistema tiene que devolver la hora en GMT. Si la zona horaria PST8PDT no est
disponible, puede establecer las reglas para esa zona horaria explicitamente.
setenv PGTZ PST8PDT7,M04.01.0,M10.05.03
Estructura de directorios
Esto debera ser una tabla en la seccin anterior.
input/ .... .Archivos fuente que son convertidos, usando 'make all', en
alguno de los archivos .sql en el subdirectorio 'sql'
output/ ... .Archivos fuente que son convertidos, usando 'make all', en
archivos .out en el subdirectorio 'expected'
sql/ ...... .Archivos sql usados para ejecutar los tests de regresin
expected/ . .Archivos .out que representan lo que *esperamos* que parezcan

los resultados
results/ .. .Archivos .out que contienen lo que los resultados *realmente*

parecen. Adems es usado como almacn temporal para el test de
copia de tablas.
Procedimiento para el test de regresin

Las instrucciones estn probadas en un RedHat Linux versin 4.2 usando el intrprete
de rdenes bash. Excepto donde se indique, seguramente funcione en la mayora de
sistemas. Instrucciones como ps y tar cambian mucho las opciones que debe usar en
cada plataforma. Use el sentido comn antes de escibir estas instrucciones.
Para una instalacin nueva o si est actualizando una versin anterior de Postgres:
Configuracin de la Regresin de Postgres
1. El archivo /usr/src/pgsql/src/test/regress/README tiene instrucciones
detalladas para la ejecucin e interpretacin de los tests de regresin. Lo que
sigue es una versin ms corta:
Si el postmaster no se est ejecutando ya, inicie el postmaster en una ventana
que est disponible escribiendo
postmaster
o inicie el demonio postmaster en segundo plano escibiendo

cd
nohup postmaster > regress.log 2>&1 &
Ejecute postmaster desde la cuenta de superusuario de Postgres (normalmente

la cuenta postgres).
No ejecute postmaster desde la cuenta de root.
2. Si ha ejecutado anteriormente los tests de regresin, borre el directorio de

trabajo con:
cd /usr/src/pgsql/src/test/regress
gmake clean
No necesita escribir "gmake clean" si es la primera vez que est ejecuntado los
tests.
3. Ejecute los tests de regresin. Escriba
gmake all
4. Ejecute los tests de regresin. Escriba

gmake runtest
5. Debera obtener en la pantalla (y adems escrito en el archivo ./regress.out) una

serie de lneas indicando qu tests han pasado y qu tests han fallado. Tenga en
cuenta que puede ser normal que alguno de los tests falle. Para los tests
fallidos, use diff para comparar los archivos de los directorios ./results y
./expected. Si falla float8, escriba algo como esto:
diff -w expected/float8.out results
6. Despus de ejecutar los tests y examinar los resultados, escriba

dropdb regression
gmake clean
para recuperar el espacio en disco temporal usado por los tests.
Anlisis de Regresin
Los resultados se encuentran en los archivos del directorio ./results. Estos resultados
pueden ser comparados con los resultados del directorio ./expected usando 'diff'. (El
guin (script) del test hace esto por usted, y deja las diferencias en ./regression.diffs.)
Los archivos pueden no corresponderse de forma exacta. El guin del test informar
deuna diferencia como "failure" (fallo), pero la diferencia puede deberse a pequeas
variaciones entre plataformas en los mensajes de error, comportamiento de la librera
matemica, etc. "Fallos" de este estilo no indican necesariamente un problema con
Postgres.
Por tanto, es necesario examinar las diferencias de cada test "fallido" con el fin de
determinar si existe un problema realmente. Los siguientes puntos intentan
proporcionar una gua para determinar si una diferencia es significativa o no.
Diferencias en los mensajes de error

Alguno de los tests de regresin incluyen intencionadamente valores de entrada no
vlidos. Los mensajes de error pueden venir tanto del cdigo de Postgres como de las
rutinas de sistema de la plataforma en la que nos encontremos. En el ltimo caso, los
mensajes pueden variar entre plataformas, pero deben reflejar informacin similar.
Estas diferencias en los mensajes darn como resultado un test "fallido" que puede
ser validado mediante una inspeccin.
Diferencias en fechas y horas

Muchos de los resultados de fecha y hora son dependientes del entorno de la zona
horaria. Los achivos de referencia estn generados para la zona horaria PST8PDT
(Berkeley, California) y aparentemente pueden parecer fallos si los tests no se
ejecutan con esta zona horaria establecida. El programa que ejecuta los tests de
regresin establece la variable de entorno PGTZ a PST8PDT para asegurar resultados
parecidos.
Parece que algunos sistemas no aceptan la sintaxis recomendada para establecer
explicitamente las reglas de la zona horaria local; puede ser que necesite usar una
forma distinta para establecer PGTZ en estas mquinas.
Algunos sistemas que usan librerias antiguas de zonas horarias fallan al aplicar las
correciones de ahorro de luz solar en las fechas anteriores a 1970, causando que las
horas de esas fechas aparezcan en PST a pesar de todo. Esto dar pie a diferencias
localizadas en los resultados de los tests.
Diferencias en punto flotante

Algunos de los tests implican calcular nmeros de 64-bits (float8) a partir de las
columnas de una tabla. Se han observado diferencias en los resultados que devuelven
funciones matemticas en columnas de tipo float8. Los tests con float8 y de
geometra son particularmente propensos a pequeas diferencias entre plataformas.
Se precisa una comparacin con lupa por parte humana para determinar diferencias
que normalmente se encuentran 10 posiciones a la derecha del punto decimal.
Algunos errores de seales del sistema con pow() y exp() difieren de los mecanismos
que espera el actual cdigo de Postgres.
Diferencias en polgonos
Varios de los tests incluyen operaciones con coordenadas sobre el callejero de
Oakland/Berkley CA. Los datos de este mapa vienen expresados como polgonos
cuyos vrtices estn representados en pares de nmeros float8 (latitud y longitud
decimal). Inicialmente, se crean y llenan algunas tablas con coordenadas, despus se
crean algunas vistas (Views) haciendo el Join de dos tablas usando el operador de
interseccin de polgonos (##), y despes se realiza un Select sobre la vista. Cuando
comparamos los resultados de diferentes plataformas, las diferencias aparecen en el
segundo o tercer lugar a la derecha del punto decimal. Las instrucciones SQL donde
se dan estos problemas son las siguientes:
QUERY: SELECT * from street;
QUERY: SELECT * from iexit;
Diferencias aleatorias
Hay al menos un caso de test en random.out que esta diseado para producir
resultados aleatorios. Esto causa que random falle el test de regresin cada vez.
Escribir
diff results/random.out expected/random.out
debe producir una o unas pocas lneas de diferencias por esta razn, pero otras
variaciones en punto flotante o en arquitecturas distintas pueden causar ms
diferencias.
Los archivos "expected"

Los archivos ./expected/*.out fueron adaptados del monoltico archivo original
expected.input proporcionado por Jolly Chen. Versiones ms modernas de estos
archivos generadas en varias mquinas de desarrollo han sido sustituidas despus de
una cuidadosa (?) inspeccin. Muchas de estas mquinas de desarrollo estn
ejecutando variantes del Unix OS (FreeBSD, Linux, etc) en hardware Ix86. El
archivo original expected.input fue creado en un sistema SPARC Solaris 2.4 usando
el cdigo de postgres5-1.02a5.tar.gz. Fue comparado con un archivo creado en un
sistema I386 Solaris 2.4 y las diferencias fueron solamente en los polgonos de punto
flotante en el tercer dgito a la derecha del punto decimal. (vea ms arriba) El archivo
original sample.regress.out se obtuvo de la entrega 1.01 de postgres construida por
Jolly Chen y se incluye aqu para referencia. Tendra que haberse ejecutado con una
mquina DEC ALPHA ya que el Makefile.global en la version 1.01 de postgres tiene
PORTNAME=alpha.
Archivos de comparacin especficos de la plataforma

Como alguno de los tests producen resultados inherentes a la plataforma usada,
hemos proporcionamos una forma para suplir los archivos de comparacin
especificos para cada plataforma. Frecuentemente se da la misma variacin en
mltiples plataformas; en vez de dar un archivo de comparacin separado para cada
plataforma, existe un archivo gua que define qu archivo de comparacin usar. De
forma que, para eliminar fallos tontos de una plataforma en particular, debe elegir o
crear un fichero de resultados variantes, y aadir una lnea al archivo gua, que es
"mapa de resultados".
Cada lnea del archivo gua es de la siguiente forma
testname/platformnamepattern=comparisonfilename
El nombre del test (testname) es sencillamente el nombre del mdulo de regresin de

ese test en particular. El patrn del nombre de la plataforma (platformnamepattern)
est generado al estilo de expr(1) (que es una expresin regular con el smbolo ^
implcito al principio). Esta se comprueba con el nombre de la plataforma tal como
viene escrito en config.guess. El nombre del fichero de comparacin
(comparisonfilename) es el nombre del sustituto del fichero de resultados de
comparacin.
Por ejemplo: el test de regresin int2 incluye una entrada deliberada de un valor que
es demasiado largo para caber en un int2. El mensaje de error especfico que es
producido es dependiente de la plataforma; nuestra plataforma de referencia saca
ERROR: pg_atoi: error reading "100000": Numerical result out of range
pero en un buen nmero de otras plataformas Unix saca

ERROR: pg_atoi: error reading "100000": Result too large
En este caso, proporcionamos una variante del archivo de comparacin, int2-too-

large.out, que incluye la sintaxis de este mensaje de error. Para no mostrar estos
"fallos" tontos en las plataformas HPPA, el resultmap (mapa de resultados) incluye
int2/hppa=int2-too-large
que se activar en cualquier mquina en el que la salida de config.guess comience por

'hppa'. Otras lneas en el resultmap seleccionan la variante del archivo de
comparacin para otras plataformas donde sea apropiado.
Version 6.5.3
Esta es basicamente una limpieza de la version 6.5.2. Hemos aadido un nuevo
pgacces que se perdio en la 6.5.2, e instalado una correcion especifica para NT.
Migracion a v6.5.3
No se requiere un dump/restores para aquellos que esten ejecutando una 6.5.*.
Lista Detallada de Cambios

Version actualizada de pgacces 0.98
Parche especifico para NT
Correccion para reglas de volcado en tablas heredadas
ersion 6.5.2
Esta es basicamente una limpieza de la version 6.5.1. Hemos corregio una variedad
de problemas reportados por usuarios de 6.5.1.
Migracion to v6.5.2
No se requiere un dump/restores para aquellos que esten ejecutando una 6.5.*.
corregidas las subselect+CASE (Tom)
Aadida configuracion de SHLIB_LINK para los portes de solaris_i386 y solaris_sparc(Daren
Correciones para CASE y WHERE en clausulas "join"(Tom)
Correcion para aborto en BTScan(Tom)
Reparada la comprobacion para UNIQUE redundante e indices PRIMARY KEY(Thomas)
Mejorado para que se compruebe las restricciones en multi-columnas(Thomas)
Correcion para Win32 que tenia problemas con MB habilitado(Hiroki Kataoka)
Permite a yacc de BSD y a bison compilar codigo pl(Bruce)
Corregido el trabajo con SET NAMES
corregidos los int8 (Thomas)
Correccion del consumo de memoria de "vacuum"(Hiroshi,Tatsuo)
Reduccion del consumo total de memoria de "vacuum"(Tom)
Correcion para timestamp(datetime)
Correcciones de problemas en las reglas de paso al analizador sintactico(Tom)
Correccion del problema de cuotas en mkMakefile.tcldefs.sh.in y mkMakefile.tkdefs.sh.in(To
This is to re-use space on index pages freed by vacuum(Vadim)
documentado -x para pg_dump(Bruce)
Correcin para operadores unarios en la regla de paso al analizador sintactico(Tom)
Comentado el FileUnlink de exceso de segmentos durante mdtruncate() (Tom)
Enlazamiento en Irix corregido por Yu Cao >yucao@falcon.kla-tencor.com<
Reparado el error logico en LIKE: no debia devolver un LIKE_ABORT
cuando alcanza el final de un patron antes del final del texto(Tom)
Reparada limpieza incorrecta de montones de memoria reservadas durante aborto de transacci
Version actualizada de pgaccess 0.98
Version 6.5.1
Esta es basicamente una limpieza de la version 6.5. Hemos corregio una variedad de
problemas reportados por usuarios de 6.5.
Migracion to v6.5.1
No se requiere un dump/restores para aquellos que esten ejecutando una 6.5.

Aadido un fichero NT LEAME
Correciones de portabilidad para linux_ppc, Irix, linux_alpha, OpenBSD, alpha
Eliminado QUERY_LIMIT, utilizar SELECT...LIMIT
Correcion para EXPLAIN en herencia(Tom)
Parche para permitir "vacuum" en tablas con multi-segmentos(Hirosi)
Correcion para la selectividad del optimizador R-Tree(Tom)
Corregida laguna el descriptor de ficheros ACL(Atsushi Ogawa)
Nueva expresion del codigo de sub arboles(Tom)
Se evitan escrituras en disco para transacciones de solo-lectura(Vadim)
Correccion para eliminacion de tablas temporales si la ultima transaccion fue abortada (Br
Correccion para prevenir que sean creadas tuplas demasiado largas(Bruce)
correciones en plpgsql
Se permiten numeros de puerto de 32k - 64k(Bruce)
Aadido ^ precidence(Bruce)
Renombrados ficheros ordendo llamados pg_temp a pg_sorttemp(Bruce)
Correcion para microsegundos en valores temporales(Tom)
Limpieza de la fuente del Tutorial
Nuevo porte a linux_m68k
Correccion para la ordenacion de NULL's en algunos casos(Tom)
Corregidas las dependencias para librerias compartidas(Tom)
Corregido fallos tecnicos que afectaban a GROUP BY en subselects(Tom)
Correccion para algunas alarmas del compilador (Tomoaki Nishiyama)
Aadido soporte para Win1250 (Checo) (Pavel Behal)
ersion 6.5
Esta version marca un avance grande en el conocimiento que el equipo de desarrollo
tiene del codigo fuente que heredamos de Berkeley. Veras que podemos aadir
mayores features mas facilmente, gracias al incremento en tamao y experiencia de
nuestro mundialmente extenso equipo de desarrollo.
He aqui un conciso sumario de los mas notables cambios:
Control de concurrencia multi-version(MVCC en ingles Multi-version concurrency
control)
Esto elimina nuestro viejo bloqueo a nivel de tabla, y lo reemplaza con un

bloqueo del sistema que es superior a la mayoria de los sistemas de bases de
datos comerciales. En un sistema tradicional, cada registro que es modificado se
bloquea hasta que se confirma la transaccion, previniendo lecturas por otros
usuario. MVCC utiliza de modo natural el caracter multi-version de PostgreSQL
para permitir que las lecturas continuen leyendo datos consistentes durante la
actividad de escritura. Las escrituras continuan utilizando el sistemas de
transacciones compacto pg_log. Todo esto se realiza sin tener que reservar un
bloqueo para cada registro como en los sistemas tradicionales de base de datos.
Asi que, basicamente, ya no estaremos restringidos por mas tiempo por el
bloqueo simple a nivel de tabla; tenemos algo mejor que el bloqueo a nivel de
registro.
Copias de seguridad en caliente con pg_dump
pg_dump se beneficia de las nuevas prestaciones de MVCC para dar

consistencia a un dump/backup mientras la base de dato pemanece en linea y
disponible para ser consultada.
Tipos de datos numericos
Ahora tenemos tipos de datos verdaderamente numericos, con precision

especificada por el usuario.
Tablas temporales
Se garantiza que las tablas temporales tienen nombres unicos durante una sesion
en la base de datos, y que son destruidas al salir de la sesion.
Nuevas prestaciones SQL

Ahora tenemos soporte para declaraciones CASE, INTERSECT, and EXCEPT.
Tenemos nuevos LIMIT/OFFSET, SET TRANSACTION ISOLATION LEVEL,
SELECT ... FOR UPDATE, y un mejorado comando LOCK TABLE.
Aceleramiento
Continuamos acelerando PostgreSQL, gracias a la variedad de talentos que hay

en nuetsro equipo. Hemos acelerdo la asignacion de memoria, la optimizacion,
las uniones de tablas (table join), y las rutinas de transferencias de registros.
Portes
Continuamos ampliando nuestra lista de portes, esta vez incluimos WinNT/ix86

y NetBSD/arm32.
Interfaces
La mayoria de interfaces tienen una nueva version, y la funcionalidad existentes

ha sido mejorada.
Documentacion
Nuevo y actualizado material esta presente por toda la documentacion. Se han

aportado nuevas FAQs para las plataformas SGI y AIX. El Tutorial tiene
informacion introductoria sobre SQL de Stefan Simkovics. Para la Guia del
Usuario, hay paginas de referencia cubriendo la utilidad postmaster y mas
programas de utilidad, un apendice nuevo contiene detalles sobre el
comportamiento de date/time. La Guia del Administrador tiene un nuevo
capitulo sobre resolucion de problemas de Tom Lane. Y la Guia del
Programador tiene una descripcion del proceso de interrogacion, tambien de
Stefan, y detalles acerca de como obtener el arbol del codigo fuente de Postgres
por CVS anonimo y CVSup.
Migracion to v6.5
Un dump/restore utilizando pg_dump es necesario para aquellos que deseen migrar
datos de cualquier version previa de Postgres. pg_upgrade not puede ser utilizado
para actualizar esta version porque la estructura en disco de las tablas ha cambiado
comparada con versiones precedentes.
La nueva caracteristica de Control de Concurrencia Multi-Version (MVCC, en ingles)
puede dar comportamientos un poco diferentes en entornos multiusuarios. Lea y
comprenda la seccion siguiente para asegurar que sus aplicaciones existentes le
proporcionaran el comportamiento que necesita.
Control de Concurrencia Multi-Version
A causa de que las lecturas en 6.5 no bloquean los datos, a pesar del nivel de
aislamiento de transaccion, los datos leidos por una transaccion pueden ser sobre
escritos por otra. En otras palabras, si un registro es devuelto por SELECT eso no
significa que este registro exista realmente en el momento en que es devuelto. (i.e
algunas veces despues de que la sentencia o la transaccion comience) ni tampoco que
el registro este protegido de ser borrado o actualizado por una transaccion en
concurrente antes de que la transccion en curso haga commit o rollback.
Para asegurar la existencia actual de un registro y protegerlo contra actulizaciones
concurrentes se debe utilizar SELECT FOR UPDATE o una sentencia LOCK
TABLE apropiada. Esto deberia ser tenido en cuento cuando se porten aplicaciones
desde versiones precedentes de Postgres y otros entornos.
Tenga todo lo anterior en mente su utiliza triggers contrib/refint.* para integridad
referencial. Ahora se requieren tecnicas adicionales. Un modo es utilizar el comando
LOCK parent_table IN SHARE ROW EXCLUSIVE MODE si una transaccion
va a actualizar/borrar una clave primaria y utilizar el comando LOCK parent_table
IN SHARE MODE si una transaccion va a actualizar/insertar una clave foranea.
Notese que si ejecuta una transaccion en modo SERIALIZABLE entonces debe
ejecutar el comando LOCK anterior antes de la ejecucion de cualquier sentencia
DML (SELECT/INSERT/DELETE/UPDATE/FETCH/COPY_TO) en la
transaccion.
Esto inconvenientes desapareceran en el futuro cuando la habilidad para leer datos

sucios (no confirmados) (a pesar del nivel de aislamiento) y la verdadera integridad
referencial sea implementada.
Lista Detalla de Cambios

Correciones de errores
---------
Correcion de las funciones de conversion text<->float8 y text<->float4(Thomas)
Correcion para creacion de tablas con constraints con mixed-case(Billy)
Cambiado comportamiento de exp()/pow() para generar error en underflow/overflow(Jan)
Correcion de error en pg_dump -z
Limpiezas de invasiones de memoria(Tatsuo)
Correcion para abortos de lo_import(Tatsuo)
Ajustes en el manejo de nombres de tipo de datos para suprimir dobles comillas(Thomas)
Uso de coersion de tipo para emparejar columnas y DEFAULT(Thomas)
Correccion de deadlock de este modo solo verifica una vez despues de un segundo de espera(
Correciones para agregaciones y PL/pgsql(Hiroshi)
Correcion para aborto de subquery(Vadim)
Correccion de libpq para la funcion PQfnumber y nombres que no distinguen mayusculas-minus
Correcion para objetos grandes escritos-en-medio, no bloques extra, consumo de memoria(Tat
Correcion para pg_dump -d o -D y entrecomillado de caracteres especiales en INSERT
Reparados serios problemas con dynahash(Tom)
Correjidos problemas de portabilidad para INET/CIDR
Correcion de problema con error de selectividad en ALTER TABLE ADD COLUMN(Bruce)
Correcion del ejecutor de ese modo trabaja merjejoin de diferentes tipos de columnas(Tom)
Correcion de error para selectividad de OR en Alpha
Correcion para problema de selectividad de indice OR(Bruce)
Correcion \d para que muestre de ese modo la extension apropiada para char()/varchar()(Rya
Correcion en el codigo del tutorial(Clark)
Mejoras en la comprobacion de destroyuser(Oliver)
Correcion para Kerberos(Rodney McDuff)
Correcion para borrado de la base de datos mientras los buffers no se han limpiado(Bruce)
Correcion la secuencia nextval() para que pueda asi distinguir mayusculas-minusculas
Correcion para operador !!=
Borrado de buffers antes de destruir los ficheros de las base de datos(Bruce)
Correcion del caso en que el ejecutor evalua las funciones dos veces(Tatsuo)
Se permite a las acciones de secuencia netxval distinguir mayusculas-minusculas(Bruce)
Correcion de optimizador de indexacion para que no trabaje para numeros negativos(Bruce)
Correcion de perdidas de memoria en ejecuciones con fjIsNull
Correcion de perdidas de memoria para aggregate(Erik Riedel)
Se permite que username contenga una almohadilla (#, dash en ingles) en los permisos GRANT
Limpieza de NULL en los tipos inet
Limpieza de errores en tablas del sistema(Tom)
Correcion de problemas de PAGER y del comando \?(Masaaki Sakaida)
Reducido el tamao de fichero de multi-segment por defecto a 1GB(Peter)
Correcion del volcado de CREATE OPERATOR(Tom)
Correccion para escaneo hacia atras de cursores(Hiroshi Inoue)
Correccion para COPY FROM STDIN cuando se utiliza \i(Tom)
Correcion para una subselect cuando es comparada dentro de una expresion(Jan)
Correcion para manejo de devolucion de error mientras se duelven registros(Tom)
Correcion de problemas con referencia a tipos de array(Tom,Jan)
Se previene oid de UPDATE SET (Jan)
Correcion de pg_dump asi a opcion -t puede manejar nombres de tabla en mayusculas-minuscu
Correciones para GROUP BY es casos especiales(Tom, Jan)
Correcion de perdidas de memoria en queries falladas(Tom)
DEFAULT soporta ahora identificadores mixed-case(Tom)
Correcion para que multi-sefment utilice DROP/RENAME de tabla, de indice(Ole Gjerde)
Dehabilitacion de uso de pg_dump con las dos opciones -o y -d(Bruce)
Se permite a pg_dump volver adecuadamente permisos de GROUP(Bruce)
Correcion para GROYP BY en INSERT INTO table SELECT * FROM table2(Jan)
Correccion para computaciones en vistas(Jan)
Correciones para agregaciones en array con indices(Tom)
Correccion para como maneja DEFAULT entrecomillado simple en valores que requieren demasia
Correccion de problema de seguridad con no super-usuarios que importan/exportan objectos d
Vuelta atras de transaccion que crea table la limpia adecuadamente(Tom)
Correccion para permitir que tablas largas y nombres de columnas generen nombres en serie
Mejoras
------------
Aadida la utilidad "vacuumdb"
Se acelera libpq por mejor asignacion de memoria(Tom)
EXPLAIN utiliza todos los indices(Tom)
Implementadas las expresiones CASE, COALESCE, NULLIF(Thomas)
Nuevo formato de salida de pg_dump(Constantin)
Aadida la cadena min()/max() a las funciones(Thomas)
Extendidas nuevo tipo de coersiones para agregaciones(Thomas)
Nueva contribucion moddatetime (Terry)
Actualizacion a pgaccess 0.96(Constantin)
Aadida rutina para byte unico en tipo de caracter "char"(Thomas)
Mejorada la funcion substr()(Thomas)
Mejorado el manejo de multi-byte (Tatsuo)
Control de concurrencia Multi-version /MVCC(Vadim)
Nuevo modo Serialized(Vadim)
Correcion para tablas por encima de 2gigs(Peter)
Nuevo SET TRANSACTION ISOLATION LEVEL(Vadim)
Nuevo LOCK TABLE IN ... MODE(Vadim)
Actualizado el driver ODBC(Byron)
Nuevo tipo de datos NUMERIC(Jan)
Nueva SELECT FOR UPDATE(Vadim)
Manejo de "NaN" e "Infinity" para valores de entrada(Jan)
Mejorado el manejo de date/year(Thomas)
Mejorado el manejo de conexiones con el motor de base de datos(backend)(Magnus)
Nuevas opciones ELOG_TIMESTAMPS y la opcion USE_SYSLOG para ficheros de registro(Massimo)
Nueva opcion TCL_ARRAYS (Massimo)
Nueva INTERSECT y EXCEPT(Stefan)
Nuevo pg_index.indisprimary para restro de claves primarias(D'Arcy)
Nuevas opcion pg_dump para permitir el borrado de tablas antes de su creacion(Brook)
Acelaracion de las rutinas de salida de registro(Tom)
Nuevo nivel de aislamiento de READ COMMITTED (Vadim)
Nuevas tablas/indices TEMP (Bruce)
Se evita el ordenamiento si el resultado ya esta ordenado(Jan)
Nueva optimizacin para la asignacion de memoria(Jan)
Se permite a psql ejecutar \p\g(Bruce)
Se permiten multiples reglas de acciones(Jan)
Aadida funcionalidad LIMIT/OFFSET (Jan)
Mejorado el optimizador cuando se unen un numero grande de tablas(Bruce)
Nueva introduccion a SQL de La Tesis de Doctorado de S. Simkovics(Stefan, Thomas)
Nueva introduccion a procesamiento del motor de base de datos (backend) de la Tesis de Doc
Mejorado el soporte para int8(Ryan Bradetich, Thomas, Tom)
Nuevas rutinas para convertir entre tipos int8 y text/varchar(Thomas)
Nuevos planes arboreos, donde se unen meta-tablas(Bruce)
Habilitadas consultas por la mano derecha por defecto(Bruce)
Se permite que el numero maximo de procesos en servidor (backends) se parametrice en el mo
(--with-maxbackends and postmaster switch (-N backends))(Tom)
GEQO por defecto tenga ahora 10 tablas porque el optimizador se acelera(Tom)
Se permite NULL=Var para MS-SQL portabilidad(Michael, Bruce)
Modificados contrib check_primary_key() y consecuentemente "automatic" or "dependent"(Anan
Se permite que psql \d en una vista muestre la consulta(Ryan)
Se acelera el LIKE(Bruce)
Correciones/prestaciones Ecpg , vease fichero src/interfaces/ecpg/ChangeLog(Michael)
Correciones/prestacines JDBC , vease src/interfaces/jdbc/CHANGELOG(Peter)
Se hace que el operador % tenga precedencia como /(Bruce)
Aadida la nueva opcion postgres -O para permitir cambios en la estructura de tablas del s
Actualizado el script contrib/pginterface/findoidjoins (Tom)
Major aceleracion en vacuum de lineas borradas con indices(Vadim)
Se permitte la ejecucion de diferentes versiones de funciones no-SQL basadas en argumentos
Aadida la opcion -E que muestra las consultas actuales enviadas pro \dt y sus amigos(Masa
Aadido numero de version en los banners de arranque de psql(Masaaki Sakaida)
Nuevo contrib/vacuumlo que elimina objetos grandes no referenciados(Peter)
Nueva inicializacion para tamaos de tablas, asi las tablas no vacuumeadas se ejecutan mej
Mejorados los mensajes de error cuando una conexion es rechazada(Tom)
Soporte para array de campos char() y varchar() (Massimo)
Revision del codigo has para incrementar fiabilidad y prestaciones(Tom)
Actualizacion a PyGreSQL 2.4(D'Arcy)
Cambiadas las opciones de depuracion asi -d4 y -d5 producen diferentes displays de nodos(J
nuevas opciones: pretty_plan, pretty_parse, pretty_rewritten(Jan)
Mejor optimizacion de estadisticas para los accesos a tablas del sistema(Tom)
Mejor manejo de tamao de bloque no por defecto(Massimo)
Mejorado el optmizador de comsumo de memoria GEQO(Tom)
UNION soporta ahora ORDER BY de columnas que no estan en la lista de target(Jan)
Mejoras grandes en libpq++ (Vince Vielhaber)
pg_dump utiliza ahora -z(ACL's) por omision(Bruce)
cache de procesos en servidor (backend), aceleracion de memoria(Tom)
Se hace que pg_dump lo haga todo en una transaccion snapshot(Vadim)
correcion de perdidas de memoria para objetos grandes, correccion para pg_dumping(Tom)
INET escribe ahora respecto a la netmask para comparaciones
Se hace que VACUUM ANALYZE solo utilice un readlock(Vadim)
Se permiten vistas (VIEW) en UNIONS(Jan)
pg_dump puede generar ahora snapshots consistentes en bases de datos activas(Vadim)
Cambios en el Arbol Fuente

-------------------
Mejorado el emparejamiento en el porte(Tom)
Correcciones de portabilidad para SunOS
Aadido porte para NT/Win32 del proceso en el servidor (backend) y se habilita carga dinam
Nuevo porte a Cobalt Qube(Mips) ejecutando Linux(Tatsuo)
Porte a NetBSD/m68k(Mr. Mutsuki Nakajima)
Porte a NetBSD/sun3(Mr. Mutsuki Nakajima)
Porte a NetBSD/macppc(Toshimi Aoki)
Correccion para configuracion de tcl/tk(Vince)
Eliminada la clave CURRENT para consultas por regla(Jan)
carga dinamica en NT ahora funciona(Daniel Horak)
Aadido soporte para ARM32(Andrew McMurry)
Mejor soporte para HPUX 11 y Unixware
Mejorado el manejo de ficheros para ser mas uniforme, previene lagunas en los descriptores
Nuevos comandos de instalacion para plpgsql(Jan)
Version 6.4
Hay muchas prestaciones nuevas y mejoras en esta version. Gracias a unestros
desarrolladores y mantenedores, casi todos los aspectos del sistema han recibido
alguna atencion desde la version anterior. He aqui un resumen, sumario incompleto:
Las vistas y las reglas son ahora funcionales gracias al extensivo nuevo codigo
en las reglas de re escritura de Jan Wieck. Tambien escribio un capitulo sobre
ello en la Guia del Programador.
Jan tambien contribuyo al segundo lenguaje procedural, PL/pgSQL, para ir con
el original lengaje procedural PL/pgTCL con el que el contribuyo la ultima
version.
Tenemos soporte opcional de caracter multiple-byte de Tatsuo Iisho para
complementar nuestro soporte local.
Las comunicaciones cliente/servidor han sido depuradas, con mejor soporte
para mensajes asincronos e interrupciones, gracias a Tom Lane.
El depurador de sintactico ejecuta ahora coersiones de tipo automatico para
emparejar argumentos a los operadores y funciones disponibles, y para
emparejar columnas y expresiones con columnas destino. Esto utiliza un
mecanismo generico que soporta las prestaciones de extensibilidad de tipo de
Postgres. Hay un nuevo capitulo en la Guia de Usuario que cubre este asunto.
Tres nuevos tipos de datos han sido anadidos. Dos tipos, inet y cidr, soportan
varias formas de trabajo en red IP, subred, y direccionamiento por maquina.
Ahora hay un tipo entero de 8 byte disponible para algunas plataformas. Vease
el capitulo de tipos de datos en la Guia del Usuario para mas detalles. Un
cuarto tipo, serial, se soporta ahora por el depurador de sintactico como una
amalgama de tipo int4, una secuencia, y un indice unico.
Han sido aadidas varias prestaciones mas sintacticas compatibles con SQL92,
incluyendo INSERT DEFAULT VALUES Several more SQL92-compatible
syntax features have been added, including INSERT DEFAULT VALUES
La instalacion y configuracion automatica del sistema ha recibido alguna
atencio, y deberia ser mas robusta para mas plataformas de lo que nunca ha
sido.
Migracion a v6.4
Se requiere un dump/restore utilizando pg_dump o pg_dumpall para aquellas que
desen migrar datos desde cualquier version anterior de Postgres.

Correciones de errores
---------
Correcion para una minuscula perdida en PQsetdb/PQfinish(Bryan)
Se elimina char2-16 de los tipos de datos, se utiliza char/varchar(Darren)
Pqfn no maneja un mensaje de NOTICE(Anders)
Reducidas elevadas esperas por ocupacion a causa de bloqueos en transacciones con muchos
Deteccion de bloqueos de transacciones atascadas (dg)
Correcion para masrcas de tiempo en estilo "ISO" en decodificacion y codificacion(Thomas)
Correccion del problema con borrado de tabla (drop) despues de deshacer (rollback) una tra
Cambiado mensaje de error y eliminado mensaje actualizado no funcional(Vadim)
Correccion para verificacion de la matriz (array) de COPY
Correccion para SELECT 1 UNION SELECT NULL
Correccion para perdidas de buffer en llamadas a objetos grandes(Pascal)
Cambio de propietario de tipo oid a int4(Bruce)
Correccion de error en la compatibilidad con oracle de las funciones btrim() ltrim() y rtr
Correccion de invalidacion en rebasamientos de cache compartida(Massimo)
Prevencion de perdidas en descriptores de ficheros en COPY's fallidos(Bruce)
Correccion para perdidas en la pg_select de libpgtcl(Constantin)
Correccion de problemas con usuario/contrasena de mas de 8 caracteres(Tom)
Correccion de problemas con manejo de NOTIFY asincronos en el proceso en servidor(backend)
Correccion de muchas entradas de sistema malas(Tom)
Mejoras
------------
Actualizacion de ecpg y ecpglib, vease src/interfaces/ecpg/ChangeLog(Michael)
Se muestra en indice utilizado en un EXPLAIN(Zeugswette)
EXPLAIN invoca una regla de sistema y muestra plan(es) para la reescritura de consultas(Ja
Conocimiento multi-byte de muchos tipos de datos y funciones, via configure(Tatsuo)
Nuevo configure con la opcion --with-mb(Tatsuo)
Nueva opcion initdb --pgencoding(Tatsuo)
Nueva opcion createdb -E multibyte(Tatsuo)
Select version(); ahora devuelve la version de PostgreSQL(Jeroen)
Libpq permite ahora clientes asincronos(Tom)
Se permite la cancelacion desde el cliente de una consulta en el proceso en servidor(backe
Psql cancelas las consultas ahora con Control-C(Tom)
Usuarios de Libpq no necesitan dar consultas dummy para obtener mensajes NOTIFY(Tom)
NOTIFY envia ahora al PID del emisor, asi que puedes decir si eras tu mismo(Tom)
La estructura de PGresult ahora incluye un mensaje de error asociado, si lo hay(Tom)
Se definen los argumentos "tz_hour" y "tz_minute" como date_part()(Thomas)
Se anaden rutinas para convertir entre varchar y bpchar(Thomas)
Se anaden runtinas para permitir el dimensionamiento de
varchar y bpchar dentro de las columnas de destino(Thomas)
Se anade un bit a las etiquetas (flags) oara soportar
zona horaria y minutos en la devolucion de fecha(Thomas)
Se permiten mas variaciones en numeros de coma flotante (por ej. ".1", "1e6")(Thomas)
Se corrigen el analisis sintactico de menores unarios empezando con espacios(Thomas)
Se implementa TIMEZONE_HOUR, TIMEZONE_MINUTE por especificaciones SQL92(Thomas)
Se verifica i se ignora adecuadamente constraints de columna FOREIGN KEY(Thomas)
SE defina USER como sinonimo de CURRENT_USER por especificacines de SQL92(Thomas)
Se habilita HAVING en clausulas pero no se corrije en ningun otro lugar aun.
Se hace el tipo "char" un sinonimo de "char(1)" (actualmente implementado como bpchar)(Tho
Se guarda el tipo de cadena si esta especificado por el manejo de la clausula DEFAULT(Thom
Operaciones de coercion abarcan diferentes tipos de datos(Thomas)
Se permite a algunos indices utilizar columnas de diferentes tipos(Thomas)
Anadidas capcidades para coersiones de tipo automatico(Thomas)
Depuraciones para objetos grandes, de este modo un fichero es truncado en su apertura(Pete
Depuraciones de la lectura de lineas(Tom)
Se permite que psql \f \ tomen los espacios en blanco como delimitadores(Bruce)
Se pasa el pg_attribute.atttypmod al frontal de la aplicacion para las longitudes de los c
Libreria de compatibilidad con Msql en /contrib(Aldrin)
Se elimina el requerimiento de que las clausulas identificadoras ORDER/GROUP BY
estuvieran incluidas en la lista de la busqueda(David)
Se convierten columnas para emparejarlas en las clausulas de UNION(Thomas)
Se elimina fork()/ecec() y solo se hace fork()(Bruce)
Depuraciones en Jdbc(Peter)
Se muestra el estado del proceso en el servidor (backend) en la
linea de comandos de ps(solo funciona en algunas plataformas)(Bruce)
Pg_hba.conf tiene ahora una opcion sameuser en el campo de la base de datos
Se hace que lo_unlink tome el parametro oid, no el int4
Nueva DISABLE_COMPLEX_MACRO para compiladores que no pueden manejar nuestras macros(Bruce)
Libpgtcl maneja los NOTIFY ahora como un evento Tcl, no se necesitan enviar consultas tont
Depuraciones en libpgtcl(Tom)
Anadida una opcion -error al comando pg_result de libpgtcl(Tom)
Anadido parche locale, vease docs/README/locale(Oleg)
Correccion para pg_dump con ella la sintaxis de CONSTRAINT y CHECK es correcta(ccb)
Nuevo codigo contrib/lo para eliminar grandes objetos huerfanos(Peter)
Nuevp comando psql "SET CLIENT_ENCODING TO 'encoding'" para prestaciones
multi.byte, vease /doc/README.mb(Tatsuo)
codigo /contrib/noupdate para revocar permisos de actualizacion en una columna
Libpq puede ser compilada ahora en win32(Magnus)
Anadido PQsetdbLogin() en libpq
Nuevo tipo entero 8-byte, comprobado por el configure del soporte para OS(Thomas)
Mejor soporte para nombres entrecomillados de tabla/columnas(Thomas)
Se rodean los nombres de tabla y columnas con dobles comillas en pg_dump(Thomas)
PQreset() trabaja ahora con contrasenas(Tom)
Handle case of GROUP BY target list column number out of range(David)
Se permite UNION en las subconsultas
Anadido auto-dimensionamiento a la pantalla a los comandos \d?(Bruce)
Se utiliza UNION para mostrar todos los resultados de \d? en una consulta(Bruce)
Se anade la prestacion de busqueda de campo \d?(Bruce)
Pg_dump utiliza menos peticiones \connect(Tom)
Se hace que la opcion -z de pg_dump trabaje mejor, se documenta en la pagina de manual(Tom
Se anade la clausula HAVING con total soporte para subconsultas y uniones(Stephan)
Texto completo de las rutinas de indexado en contrib/fulltextindex(Maarten)
Los ids de transacciones se almacenan ahora en memoria compartida(Vadim)
Nuevo PGCLIENTENCODING cuando ejecutan el comando COPY(Tatsuo)
Soporte para la sintaxis SQL92 "SET NAMES"(Tatsuo)
Soporte para LATIN2-5(Tatsuo)
Anadido el caso UNICODE los test de refresion(Tatsuo)
Depuracion de gestor de bloqueos, nuevos modos de bloqueos para LLL(Vadim)
Se permite el uso de indice en clausulas OR(Bruce)
Se permite "SELECT NULL ORDER BY 1;"
La explicacion VERBOSE del plan lo imprime, y ahora imprime en bonito el plan al
fichero de log del postmaster(Bruce)
Se anaden indices al display para el comando \d(Bruce)
Se permite el GROUP BY en funciones(David)
Nuevo pg_class.relkind para obejtos grandes(Bruce)
Nuevo modo de enviar libpq mensajes NOTICE a diferentes localizaciones(Tom)
Nuevo comando de escritura \w para psql(Bruce)
Nuevo /contrib/findoidjoins escanea columnas oid para encontrar relaciones de union(Bruce)
Se permite que sean considerados indices compatibles binarios cuando se verifican
indices validos para una clausula de restriccion conteniendo una constante(Thomas)
Nuevo codigo ISBN/ISSN en /contrib/isbn_issn
Se permite NOT LIKE, IN, NOT IN, BETWEEN, y NOT BETWEEN constraint(Thomas)
Nuevo sistema de reescritura corrige muchos problemas con reglas y vistas(Jan)
* Reglas en trabajos relacionados
* Cualificaciones de eventos en trabajos de inserciones/actualizaciones/borrados
* Nueva variable OLD para referirse a CURRENT, CURRENT se eliminara en un futuro
* Las reglas de actualizacion se pueden referir a NEW y OLD en la regla cualificac
* Inserciones/actualizaciones/borrados en vistas de trabajo
* Reglas multiples de accion se soportan ahora, rodeadas entre parentesis
* Usuarios normales pueden crear vistas/reglas en las tablas en las que tengan per
* Las reglas y las vistas heredan los permisos del creador
* No hay reglas a nivel de columna
* No hay reglas de ACTUALIZACION NUEVA/VIEJA (UPDATE NEW/OLD)
* Nuevas vistas de sistema pg_tables, pg_indexes, pg_rules y pg_views
* Solo se puede ejecutar una accion en las reglas de SELECT
* Re escritura total revisada, tal vez para la 6.5
* manejo de subselects
* manejo de agregaciones en vistas
* manejo de inserciones dentro de una seleccion desde una vista ahora funciona
Los indices del sisteme ahora son multi-clave(Bruce)
Los tipos Oidint2, oidint4, y oidname types se eliminan(Bruce)
Se utiliza cache del sistema para mas busquedas en tablas del sistema(Bruce)
Nueva lenguaje de programacion en el proceso en servidor(backend) PL/pgSQL en backend/pl(J
El nuevo tipo de datos SERIAL, auto crea la secuencia/indice(Thomas)
Se permite la comprobacion de declaraciones sin recompilar(Massimo)
Mejoras en el bloqueo de usuario(Massimo)
Nuevo comando setval() para configurar el valor de una secuencia(Massimo)
Auto eliminacion del fichero de socket de unixsi no hay un postmaster ejecutandose(Massimo
Paquete de traceo condicional(Massimo)
Nuevo comando UNLISTEN(Massimo)
Psql y libpq se compilan ahora bajo win32 utilizando win32.mak(Magnus)
Lo_read ya no almacena rastros NULL (Bruce)
Los identificadores son truncados ahora internamente a 31 caracteres(Bruce)
Opciones de createuser estan disponibles ahora en la linea de comando
Anadido soporte para codigo de enteros de 64-bit, configuracion comprobada, tipos de int8(
Se previene la perdida de un descriptor a causa de un COPY fallido(Bruce)
Nuevo comando pg_upgrade(Bruce)
Directorios Updated /contrib (Massimo)
Nueva setencia CREATE TABLE DEFAULT VALUES disponible(Thomas)
Nueva sentencia INSERT INTO TABLE DEFAULT VALUES disponible(Thomas)
Nueva prestacin DECLARE y FETCH(Thomas)
Estructuras internas de libpq ahora no se exportan (Tom)
Se permiten indices con mas de 8 claves(Bruce)
Se elimina el teclado ARCHIVE, que ya no se utiliza(Thomas)
La opcion -n de pg_dump para suprimir comillas alrededor de los identificadores
se deshabilita las columnas del sistema para las vistas(Jan)
nuevos tipos INET y CIDR para direcciones de red(TomH, Paul)
No mas comillas en las salidas de psql
pg_dump ahora vuelca las vistas(Terry)
nuevo SET QUERY_LIMIT(Tatsuo,Jan)
Cambios en el Arbol Fuente

-------------------
Limpieza de /contrib (Jun)
Enlazadas algunas pequenas funciones llamadas para cada registro(Bruce)
Inline some small functions called for every row(Bruce)
Correcciones paraAlpha/linux
Limpiezas para Hp/UX (Tom)
Test de regresion para Multi-byte (Soonmyung.)
Se elimina la opcion --disabled del configure
Se define PGDOC para que utilice POSTGRESDIR por defecto
Se hace la regresion opcional
Se eliminan corchetes extras en el codigo de pgindent(Bruce)
Se anade soporte para la libreria compartida bsdi(Bruce)
Nueva soporte para opcion de configuracion --without-CXX support(Brook)
Nueva FAQ_CVS
Actualizado flowchart de proceso de servidor en tools/backend(backend)
Cambiado atttymod de int16 a int32(Bruce, Tom)
Se corrige Getrusage() para plataformas que no lo tienen(Tom)
Se anade PQconnectdb, PGUSER, PGPASSWORD a la pagina de manual de libpq
NS32K platform fixes(Phil Nelson, John Buller)
Correcciones para Sco 7/UnixWare 2.x (Billy,others)
Correccines para Sparc/Solaris 2.5 (Ryan)
Pgbuiltin.3 esta obsoleto, movido a los ficheros de documentacion(Thomas)
Aun mas documentacion(Thomas)
Soporte para Nexstep(Jacek)
Soporte para Aix (David)
Pagina de manual para pginterface(Bruce)
Todas las librerias compartidas tienen numero de version
Unidas todos los defines de las librerias compartidas de SO-especificos dentro de un unico
Comprobacion de configuracion TCL/TK mas inteligente(Billy)
Configuracion de perl mas inteligente(Brook)
confdigure utiliza install-sh facilitado si no se encuentra script de instalacion(Tom)
nueva Makefile.shlib para configuracion de librerias compartidas(Tom)
DESCRIPCIN DEL VDEO

Parmetros en postgresql.conf:
track_activities
track_counts
track_io_timing
track_functions
update_process_title
Otros:
log_min_duration_statement / log_connections / log_statement
Algunas vistas y catlogos de inters:

pg_stat_activity
pg_stat_database
pg_stat_all_tables
pg_stat_user_functions
pg_stat_all_indexes
pg_locks
Emergencia: pg_terminate_backend, pg_cancel_backend
Referencias:
http://www.postgresql.org/docs/current/interactive/monitoring-stats.html
http://www.postgresql.org/docs/current/interactive/runtime-config-statistics.html
Ejemplos:
-- conexiones actuales
SELECT datname,usename,current_query FROM pg_stat_activity ;
-- consultas activas
SELECT datname,usename,current_query
FROM pg_stat_activity
WHERE current_query != '<IDLE>' ;
-- consultas que llevan largo tiempo de ejecucion

select
current_timestamp - query_start as runtime,
datname,
usename,
current_query
from pg_stat_activity
where current_query != '<IDLE>'
order by 1 desc;
-- consultas en espera
SELECT datname,usename,current_query
WHERE waiting = true;
-- detalle de bloqueos que mantienen consultas en espera

SELECT
w.current_query as waiting_query,
w.procpid as w_pid,
w.usename as w_user,
l.current_query as locking_query,
l.procpid as l_pid,
l.usename as l_user,
t.schemaname || '.' || t.relname as tablename
from pg_stat_activity w
join pg_locks l1 on w.procpid = l1.pid and not l1.granted
join pg_locks l2 on l1.relation = l2.relation and l2.granted
join pg_stat_activity l on l2.pid = l.procpid
join pg_stat_user_tables t on l1.relation = t.relid
where w.waiting;
-- Terminar transacciones que quedaron pendientes por mucho tiempo

select pg_terminate_backend(procpid)
from pg_stat_activity
where current_query = '<IDLE> in transaction'
and current_timestamp - query_start > '10 min';
-- Se est usando una tabla?

create temp table tmp_stat_user_tables as
select * from pg_stat_user_tables;
-- luego de un rato
select * from pg_stat_user_tables n
join tmp_stat_user_tables t
on n.relid=t.relid
and (n.seq_scan,n.idx_scan,n.n_tup_ins,n.n_tup_upd,n.n_tup_del) <>
(t.seq_scan,t.idx_scan,t.n_tup_ins,t.n_tup_upd,t.n_tup_del);
Monitorizacin
Vie, 18/02/2011 - 15:07 rafaelma
Una de las tareas ms importantes de un administrador de bases de datos es monitorizar

los sistemas a su cargo para saber como estn funcionando y planear futuras
modificaciones y actualizaciones de los mismos.
Este artculo es una introduccin a la monitorizacin de sistemas de bases de datos en

sistemas Linux/Unix y est basado en un entrenamiento especializado que se impartio en
el PGDay Latinoamericano 2011 en Cuba. Ms adelante escribiremos otros artculos ms especficos que
nos ayuden a usar e interpretar los datos obtenidos de monitorizar nuestros sistemas.
En nuestro caso, monitorizar significa vigilar el funcionamiento de un sistema, servicio o actividad. Bajo
nuestro punto de vista existen dos tipos de monitorizacin:
Ad Hoc: Monitorizacin especfica en caso de problemas o pruebas. Se utiliza generalmente para

investigar una situacin puntual en la que intentamos encontrar una explicacin a un suceso,
cambio o problema.
Preventiva: Detecta interrupciones de servicios, alerta sobre posibles problemas y crea grficos
con tendencias y datos histricos sobre nuestros sistemas. Este tipo de monitorizacin est
automatizada y nos ayuda a descubrir cambios en nuestros sistemas que provocan o pueden
provocar problemas en un futuro cercano.
Existen numerosos programas que nos pueden ayudar a realizar la monitorizacin de nuestros sistemas
PostgreSQL. A continuacin teneis los mas usados en el mundo de programas de cdigo abierto.
Ad Hoc: vmstat, iostat, sar, ps, top, iotop, htop, etc en la linea de comandos de vuestro sistema
operativo, e informacin interna de vuestra instalacion postgreSQL via las vistas y tablas de
sistema en la base de datos.
Preventiva: "Nagios" para detectar y alertar sobre posibles problemas y "Munin" para crear
grficas histricas con las tendencias y uso de nuestros sistemas.
Los elementos a monitorizar son todos aquellos que nos puedan dar informacin sobre como nuestro
sistema est funcionando y comportandose. Tendremos que monitorizar los componentes de la
infraestructura necesaria para que nuestro sistema funcione, los servidores que estamos utilizando, el
uso de los recursos que se estn utilizando y la informacin interna en la base de datos que nos de datos
sobre como se est usando PostgreSQL.
Algunos de los elementos ms importantes que se suelen monitorizar son los siguientes:
Servidor: Disponibilidad y posibles problemas del hardware

CPU: Carga del sistema y uso de la CPU
Memoria: Carga y uso de la memoria, uso de la memoria de intercambio (swap)
Red: Disponibilidad de los componentes de red, trfico de entrada y salida.
Discos / almacenamiento: Espacio utilizado, I/O (Input/Output) del sistema
PostgreSQL: Nmero de conexiones, nmero de transacciones, transacciones abiertas, bloqueos,
espacio usado, tipo de comandos usados, etc, etc
Ademas de estos elementos, suelen existir caractersticas especficas a cada sistema que cada
administrador deber identificar y monitorizar de la mejor manera posible.
Monitorizacin Ad Hoc
Como ya hemos comentado, este tipo de monitorizacin se utiliza generalmente para investigar una
situacion puntual, en la que entramos en el sistema, recogemos los datos deseados por un periodo de
tiempo y pasamos a su posterior anlisis para intentar encontrar una explicacin a la situacin o
problema que estamos intentado resolver.
Herramientas del sistema operativo
A continuacin teneis una breve introduccin a las herramientas del sistema operativo usadas ms a
menudo en esta monitorizacin. Todas estas herramientas se pueden usar con multitud de opciones y
parmetros, para obtener informacin detallada sobre los mismos usar el comando "man programa"
vmstat: Este comando se suele usar para obtener, entre otras cosas, informacin sobre el uso de
memoria, swap, I/O total y cpu del sistema. La primera fila del resultado por defecto da los valores
medios desde la ltima vez que se arranco el sistema. Es un programa que te da informacin global e
instantanea del sistema en un momento determinado.
En sistemas debian/ubuntu este programa esta incluido en el paquete procps y si no esta instalado se
puede instalar con el siguiente comando:
$ sudo apt-get install procps
Un resultado tpico de ejecutar este comando podria ser el siguiente:
$ vmstat -n 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 1368 401736 529112 4844136 0 0 15 26 24 6 5 1 94 1
0 0 1368 397884 529112 4844140 0 0 0 124 523 1399 1 0 99 0
0 0 1368 401976 529112 4844140 0 0 0 0 566 1648 1 0 99 0
0 0 1368 398752 529112 4844140 0 0 0 0 488 1447 1 0 99 0
0 0 1368 403588 529112 4844140 0 0 0 0 520 1550 2 0 98 0
0 0 1368 398720 529112 4844140 0 0 0 0 565 1525 1 0 99 0
0 0 1368 400232 529116 4844144 0 0 0 124 551 1609 1 0 99 0
0 0 1368 396132 529116 4844144 0 0 0 0 519 1395 1 0 99 0
0 0 1368 400720 529116 4844144 0 0 0 440 673 1892 1 0 98 1
1 0 1368 397076 529116 4844144 0 0 0 0 500 1443 1 1 99 0
El tamao de bloque por defecto es 1024 bytes (1Kb) y el significado de las distintas columnas es el
siguiente:
r: Procesos esperando por tiempo de ejecucin (run time)

b: Procesos en estado de espera sin interrupciones(uninterruptible sleep)
swpd: Cantidad de memoria virtual en uso

free: Cantidad de memoria ociosa
buff: Cantidad de memoria usada por buffers
cache: Cantidad de memoria usada caches
si: Cantidad de memoria grabada en disco (swap-in)

so: Cantidad de memoria leida del disco (swap-out)
bi: Bloques recibidos por los dispositivos de bloques (bloques/s)

bo: Bloques enviados por los dispositivos de bloques (bloques/s)
in: Nmero de interrupciones por segundo

cs: Nmero de cambios de contexto por segundo (context switches)
us: Tiempo de cpu de procesos de usuario (nice incluido)

sy: Tiempo de cpu de procesos del kernel
id: Tiempo de cpu ocioso
wa: Tiempo de cpu esperando por I/O
st: Tiempo de cpu "robado" a una maquina virtual
iostat: Este comando se suele utilizar para obtener informacin sobre la entrada/salida de datos de todos
los dispositivos, particiones y sistemas de ficheros NFS. Por defecto, el primer resultado da los valores
medios desde la ltima vez que se arranco el sistema. Es un programa que te da informacin sobre el I/O
del sistema para todos los dispositivos en un momento determinado.
En sistemas debian/ubuntu este programa est incluido en el paquete sysstat y si no esta instalado se
$ sudo apt-get install sysstat
Un resultado tpico de ejecutar este comando podria ser el siguiente:
$ iostat -k -p 1 2
avg-cpu: %user %nice %system %iowait %steal %idle
4.78 0.19 0.60 0.79 0.00 93.64
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 5.50 59.00 106.86 19921681 36081584
sda1 1.62 6.75 17.93 2279650 6053108
sda2 0.08 3.05 0.02 1031003 7032
sda3 3.80 49.19 88.91 16610176 30020076
sda4 0.00 0.00 0.00 740 1368
sdb 0.00 0.01 0.00 3460 44
sdb1 0.00 0.01 0.00 3340 44
avg-cpu: %user %nice %system %iowait %steal %idle
0.99 0.10 0.54 0.00 0.00 98.37
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.20 25.60 0.00 128 0
sda1 0.00 0.00 0.00 0 0
sda2 0.20 25.60 0.00 128 0
sda3 0.00 0.00 0.00 0 0
sda4 0.00 0.00 0.00 0 0
sdb 0.00 0.00 0.00 0 0
sdb1 0.00 0.00 0.00 0 0
El tamao de bloque por defecto usado por este programa es 512 bytes. El parmetro -k nos cambia el
valor de bloque a 1024 bytes (1Kb). El significado de las distintas columnas es el siguiente:
tps: Nmero de peticiones I/O (transferencias) a un dispositivo

kB_read/s: kB por segundo leidos del dispositivo
kB_wrtn/s: kB por segundo escritos en el dispositivo
kB_read: Nmero total de kB leidos del dispositivo
kB_wrtn: Nmero total de kB escritos en el dispositivo
sar: Este programa se suele utilizar para recolectar y grabar informacin sobre nuestro sistema durante
un periodo de tiempo.
En sistemas debian/ubuntu este programa est incluido en el paquete sysstat y si no esta instalado se
$ sudo apt-get install sysstat
La recoleccin de datos se llama desde cron (/etc/cron.d/sysstat), y por defecto no est activado. Para
activar la recoleccin de datos una vez instalado deberemos cambiar un parmetro en el fichero
/etc/default/sysstat y arrancar el servicio:
ENABLE="TRUE" en /etc/default/sysstat
$ sudo /etc/init.d/sysstat restart
Un resultado tpico de ejecutar este comando despues de un tiempo desde que se activa la recoleccin de
datos podria ser el siguiente:
$ sar
Linux 2.6.35-24-generic (core2) 01/29/2011 _x86_64_ (4 CPU)
12:00:01 AM CPU %user %nice %system %iowait %steal %idle
12:05:01 AM all 0.72 0.14 0.95 0.19 0.00 97.99
12:15:01 AM all 0.74 0.15 0.95 0.09 0.00 98.07
12:25:01 AM all 0.73 0.15 0.90 0.05 0.00 98.17
12:35:01 AM all 0.74 0.14 0.93 0.15 0.00 98.05
12:45:01 AM all 1.08 4.80 3.27 0.07 0.00 90.78
12:55:01 AM all 0.96 3.67 2.59 0.10 0.00 92.68
01:05:01 AM all 0.72 0.14 0.90 0.19 0.00 98.04
01:15:01 AM all 0.76 0.13 0.97 0.07 0.00 98.06
01:25:01 AM all 0.70 0.15 0.90 0.06 0.00 98.20
01:35:01 AM all 0.70 0.13 0.89 0.11 0.00 98.17
01:45:01 AM all 0.68 0.14 0.90 0.10 0.00 98.18
ps: Este programa nos da informacin sobre los procesos que se estn ejecutando en nuestro sistema. En
el caso de procesos PostgreSQL nos puede dar informacin muy valiosa sobre cuantos procesos
PostgreSQL se estn ejecutando y que estn haciendo.
Un resultado tpico de ejecutar este comando para obtener los procesos PostgreSQL del sistema,
ordenados por el momento en que empezaron a ejecutarse, podria ser el siguiente:
$ ps auxww | grep "postgres: " | sort -k 9
postgres 30758 .... 07:10 0:00 postgres: autovacuum launcher process
postgres 30759 .... 07:10 0:00 postgres: stats collector process
postgres 30757 .... 07:10 0:00 postgres: wal writer process
postgres 30756 .... 07:10 0:01 postgres: writer process
postgres 862 .... 07:59 0:00 postgres: postgres postgres [local] idle in transaction
postgres 1921 .... 09:22 0:00 postgres: postgres postgres 127.0.0.1(39475) idle
postgres 21074 .... 14:14 0:04 postgres: postgres pgbench [local] COMMIT
postgres 21073 .... 14:14 0:04 postgres: postgres pgbench [local] UPDATE waiting
Los que nos suelen interesar en este caso son los procesos creados por conexiones de clientes a nuestro
servidor PostgreSQL. Estos procesos se muestran con el siguiente formato:
postgres: usuario dbase maquina(puerto) actividad
Como podeis ver, podemos obtener informacin sobre que usuario est utilizando el cliente para
conectarse, a que base de datos se est conectando, desde que mquina y puerto (o socket [local]) se ha
conectado y que est haciendo. Los valores de la actividad que est realizando podrn ser:
idle in transaction: El proceso ha abierto una transaccin pero no la ha cerrado todavia.

idle: El proceso est conectado pero sin hacer nada.
COMANDO: El proceso est ejecutando el comando COMANDO
COMANDO waiting: El proceso quiere ejecutar el comando COMANDO, pero est bloqueado y esperando a
poder ejecutarse
Vistas y tablas de sistema internas en PostgreSQL
Adems podemos obtener informacin sobre como esta funcionando PostgreSQL internamente a travs
de las vistas y tablas de sistema en la base de datos. En sucesivos artculos iremos viendo que tipo de
informacin contienen y como interpretar estas vista/tablas de sistema.
Para que muchas de estas vistas/tablas funcionen debemos tener activados estos parmetros en nuestro
sistema, track_counts, track_functions, track_activities, bien en el fichero postgresql.conf o definidos con SET /
ALTER DATABASE en la sesin o base de datos de la que queremos obtener informacin.
Existen muchas vistas y tablas internas pero las que se usan mas comunmente para obtener informacin
de PostgreSQL son las siguientes:
pg_roles: Informacin sobre todos los roles y usuarios definidos en la base de datos.
postgres=# SELECT * from pg_roles ;
rolname | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcatupdate | rolcanlogin | rolconnlimit | rolpassword | rolvaliduntil |
rolconfig | oid
----------+----------+------------+---------------+-------------+--------------+-------------+--------------+-------------+---------------
+-----------+-----
postgres | t |t |t |t |t |t | -1 | ******** | | | 10
(1 row)
pg_database Informacin sobre todas las bases de datos definidas en nuestro sistema.
postgres=# SELECT * from pg_database ;
datname | datdba | encoding | datcollate | datctype | datistemplate | datallowconn | datconnlimit | datlastsysoid | datfrozenxid |
dattablespace | datacl
-----------+--------+----------+-------------+-------------+---------------+--------------+--------------+---------------+--------------
+---------------+-------------------------------------
template1 | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | t |t | -1 | 11866 | 654 | 1663 |

{=c/postgres,postgres=CTc/postgres}
template0 | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | t |f | -1 | 11866 | 654 | 1663 |

{=c/postgres,postgres=CTc/postgres}
postgres | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | f |t | -1 | 11866 | 654 | 1663 |
pgbench | 10 | 6 | en_US.UTF-8 | en_US.UTF-8 | f |t | -1 | 11866 | 654 | 1663 |
(4 rows)
pg_locks: Informacin sobre los bloqueos activos en nuestras bases de datos. Vista complicada de
entender pero muy valiosa en ciertas situaciones.
postgres=# SELECT * from pg_locks ;
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid |
mode | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------
+------------------+---------
relation | 16385 | 16392 | | | | | | | | 3/2666 | 2711 | AccessShareLock | t
relation | 16385 | 16392 | | | | | | | | 3/2666 | 2711 | RowExclusiveLock | t
virtualxid | | | | | 4/2692 | | | | | 4/2692 | 2710 | ExclusiveLock |t

tuple | 16385 | 16389 | 22 | 97 | | | | | | 4/2692 | 2710 | ExclusiveLock |t
transactionid | | | | | | 2793613 | | | | 4/2692 | 2710 | ExclusiveLock |t
transactionid | | | | | | 2793614 | | | | 3/2666 | 2711 | ExclusiveLock |t
transactionid | | | | | | 2793609 | | | | 4/2692 | 2710 | ShareLock |t
(23 rows)
pg_stat_activity: Informacin sobre todos los procesos clientes conectados a la base de datos.
postgres=# SELECT * from pg_stat_activity ;
datid | datname | procpid | usesysid | usename | application_name | client_addr | client_port | backend_start |

xact_start | query_start | wa
iting | current_query
-------+----------+---------+----------+----------+------------------+-------------+-------------+-------------------------------
+-------------------------------+-------------------------------+---------+-----------------------------------------------------------------------
11874 | postgres | 2401 | 10 | postgres | psql | | -1 | 2011-02-17 22:48:08.090603+01 | 2011-02-17

22:52:31.297037+01 | 2011-02-17 22:52:31.297037+01 | f | SELECT * from pg_stat_activity ;
16385 | pgbench | 2711 | 10 | postgres | | | -1 | 2011-02-17 22:51:12.209724+01 | 2011-02-17

22:52:31.296394+01 | 2011-02-17 22:52:31.296873+01 | f | END;
16385 | pgbench | 2710 | 10 | postgres | | | -1 | 2011-02-17 22:51:12.1963+01 | 2011-02-17

22:52:31.295193+01 | 2011-02-17 22:52:31.29542+01 | t | UPDATE pgbench_tellers SET tbalance = tbalance + -4443 WHERE tid
= 1;
16385 | pgbench | 2811 | 10 | postgres | | | | 2011-02-17 22:52:27.549785+01 | 2011-02-17

22:52:31.247453+01 | 2011-02-17 22:52:31.247453+01 | f | autovacuum: ANALYZE public.pgbench_history
(4 rows)
pg_stat_database: Informacin global de uso de todas las bases de datos.
postgres=# SELECT * from pg_stat_database ;
datid | datname | numbackends | xact_commit | xact_rollback | blks_read | blks_hit | tup_returned | tup_fetched | tup_inserted |
tup_updated | tup_deleted
-------+-----------+-------------+-------------+---------------+-----------+----------+--------------+-------------+--------------+-------------
+-------------
1 | template1 | 0| 3612 | 0| 2840 | 100341 | 935386 | 33760 | 0| 0|

0
11866 | template0 | 0| 0| 0| 0| 0| 0| 0| 0| 0| 0
11874 | postgres | 1| 4859 | 0| 1304 | 132667 | 1425972 | 38209 | 0| 0| 0
16385 | pgbench | 2| 2978446 | 1| 659578 | 82868995 | 41262336 | 11863286 | 3178023 |

8934189 | 0
(4 rows)
pg_stat_user_tables: Informacin de uso de todas las tablas de usuario en una base de datos
pgbench=# SELECT * from pg_stat_user_tables ;
relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del |
n_tup_hot_upd | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze |
last_autoanalyze
-------+------------+------------------+----------+--------------+----------+---------------+-----------+-----------+-----------+---------------
+------------+------------+-------------------------------+-------------------------------+-------------------------------
+-------------------------------
16395 | public | pgbench_history | 0| 0| | | 3074221 | 0| 0| 0| 283308 |

0 | 2011-01-29 12:31:54.208813+01 | | 2011-01-29 12:31:54.209202+01 | 2011-02-17 22:53:34.126245+01
16386 | public | pgbench_branches | 38821 | 62452 | 3042999 | 3042999 | 2 | 3074222 | 0| 3072054

| 75 | 493 | 2011-02-17 22:51:12.172321+01 | 2011-02-17 22:53:27.711111+01 | 2011-01-29 12:31:53.945088+01 |
2011-02-17 22:53:27.748393+01
16389 | public | pgbench_tellers | 32474 | 621300 | 3043158 | 3043158 | 20 | 3074222 | 0| 3052868 |

55 | 810 | 2011-02-17 22:51:12.175635+01 | 2011-02-17 22:53:27.870574+01 | 2011-01-29 12:31:53.946838+01 | 2011-02-17
22:53:27.871727+01
16392 | public | pgbench_accounts | 1| 200000 | 6148444 | 6148444 | 200000 | 3074222 | 0|

3033380 | 199999 | 10091 | 2011-01-29 12:31:54.049578+01 | 2011-01-29 12:59:29.982391+01 | 2011-01-29
12:31:54.204138+01 | 2011-02-17 22:53:31.476969+01
(4 rows)
pg_stat_user_indexes: Informacin de uso de todos los ndices de usuarios en una base de datos
pgbench=# SELECT * from pg_stat_user_indexes ;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16386 | 16399 | public | pgbench_branches | pgbench_branches_pkey | 3088826 | 10145852 | 2902404
16389 | 16401 | public | pgbench_tellers | pgbench_tellers_pkey | 3088985 | 24680003 | 2378762
16392 | 16403 | public | pgbench_accounts | pgbench_accounts_pkey | 6240098 | 6319966 | 6240098
pg_stat_user_functions: Informacin sobre estadsticas de uso de las funciones en uso.
pg_statio_user_tables: Informacin de acceso a disco y memoria cache de todas las tablas de usuario en
una base de datos.
pgbench=# SELECT * from pg_statio_user_tables ;
relid | schemaname | relname | heap_blks_read | heap_blks_hit | idx_blks_read | idx_blks_hit | toast_blks_read | toast_blks_hit

| tidx_blks_read | tidx_blks_hit
-------+------------+------------------+----------------+---------------+---------------+--------------+-----------------+----------------
+----------------+---------------
16392 | public | pgbench_accounts | 547836 | 9289403 | 1361 | 19151376 | | | |
16395 | public | pgbench_history | 135074 | 3208010 | | | | | |
16386 | public | pgbench_branches | 7587 | 17015504 | 6| 3138237 | | | |

16389 | public | pgbench_tellers | 7160 | 28805005 | 25 | 6021187 | | | |
(4 rows)
pg_statio_user_indexes: Informacin de acceso a disco y memoria cache de todos los ndices de usuario
en una base de datos.
pgbench=# SELECT * from pg_statio_user_indexes ;
relid | indexrelid | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
-------+------------+------------+------------------+-----------------------+---------------+--------------
16386 | 16399 | public | pgbench_branches | pgbench_branches_pkey | 6| 3163169
16389 | 16401 | public | pgbench_tellers | pgbench_tellers_pkey | 25 | 6076626
16392 | 16403 | public | pgbench_accounts | pgbench_accounts_pkey | 1361 | 19301010
(3 rows)
pg_stat_bgwriter: Informacin global sobre el proceso "background writer"
pgbench=# SELECT * from pg_stat_bgwriter ;
checkpoints_timed | checkpoints_req | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_alloc
-------------------+-----------------+--------------------+---------------+------------------+-----------------+---------------
474 | 81 | 223942 | 554746 | 573 | 85369 | 555848
(1 row)
Monitorizacin preventiva
Como hemos comentado al principio, este tipo de monitorizacin se utiliza para detectar interrupciones
de servicios, alertar sobre posibles problemas y crea grficos con tendencias y datos histricos sobre
nuestros sistemas. Los dos programas de cdigo abierto mas utilizados para este tipo de monitorizacin
son:
Nagios: Se utiliza para detectar interrupciones de servicios y alertar sobre posibles problemas o
situaciones que necesitan una atencin especial por parte de los administradores del sistema. Su
instalacin y configuracin se escapa al objetivo de este documento. Ms adelante escribiremos
un artculo sobre como utilizar Nagios.
Aqu teneis un ejemplo de una de la pantallas de este programa:
Munin: Se utiliza para crear grficas histricas con las tendencias y uso de nuestros sistemas.
Imprescindible para ver como nuestros sistemas se estn utilizando en el tiempo y si existen
tendencias en el uso que van a requerir nuestra intervencin en el futuro. Su instalacin y
configuracin se escapa al objetivo de este documento. Ms adelante escribiremos un artculo
sobre como utilizar Munin.
Aqu teneis algunos ejemplos de lo que se puede hacer con este programa:
Ms informacin
Consideraciones Preliminares
Antes de comenzar debemos tener en cuenta a que plataformas est destinado este White Paper:
Sistema Operativo: Linux, Windows. Otros derivados de Unix podran incluirse.

Base de Datos: Postgresql 8.1 a 8.3
En este documento, ud. encontrar los caminos para monitorear un servidor Postgresql
utilizando las herramientas incorporadas en el sistema operativo ms, algunas adicionales que
pueden ser descargas gratuitamente desde el sitio pgfoundry.org (repositorio oficial de Postgresql).
Para entender de manera cabal este White Paper, le aconsejamos tener conocimientos bsicos
de programacin sobre bash (GNU/Linux y derivados de Unix) y batch en Windows. Tambin
deber conocer muy pequeos conceptos de expresiones regulares en Perl o Python, pero no sern
obligatorios en un principio.
Objetivos de la monitorizacin
Los fines principales de monitorear un servidor de bases de datos son:
Verificar el consumo de recursos.

Actividad positiva del mismo.
Tiempo de respuesta del servidor.
Recabar la mayor cantidad de informacin a fin de poder tener los suficientes datos para
ubicar donde esta el problema.
Deteccin de problemas de hard o red.
Obtener informacin de una determinada tarea o consulta (especial para puesta a punto de
sentencias o servidor).
Por lo que deducimos que tenemos tres grupos: actividad del motor, comportamiento del
servidor e investigacin de consultas.
Informacin sobre procesos
Los procesos son tareas que se ejecutan con una cuota de tiempo en el procesador. Cada
proceso, puede tener hilos de ejecucin internos, simulando tener varios procesos hijos. Los
procesos pueden consumir rangos de memoria y tiempos de procesamiento determinados en la
configuracin del sistema operativo y desde las aplicaciones o herramientas que los lanzan.
Sin embargo, es el SO quien administra de manera transparente al usuario dichas asignaciones

(aunque uno pueda asignar determinados retoques desde el SO). Para tales ajustes, es requerido
poseer privilegios desde el sistema operativo para poder asignarlas.
Los procesos tienen asignados una prioridad. Es esta la que le indica al sistema operativo
cuanto tiempo y cantidad de recursos de procesador le asignar. En el caso especfico de
plataformas Unix o derivadas, este valor puede ir de -20 a 20, siendo la menor, la ms prioritaria.
En Windows, desde el Administrador de Tareas, ctfmon.exe o tasklist desde la lnea de comandos,
podremos observar 6 niveles de prioridades que van desde 'Tiempo Real' a 'Baja'.
Algunos sistemas operativos, tienen mecanismos avanzados de asignacin de permisos, tal

como Solaris. Este, tiene la opcin de FP (Fixed Priority) el cual ir variando la prioridad de
acuerdo al uso de los procesos.
Adems, podemos considerar el nivel de intrusividad del monitoreo. A mayor cantidad de

informacin recolectada, ms se ver afectado el sistema. Sin embargo y por lo general, los
monitoreos no suelen ser consumidores abruptos de recursos.
A diferencia de la monitorizacin normal, existen los benchmarks. Estas tcnicas, permiten

medir el rendimiento de un determinado servidor, ya sea con datos ficticios y aleatorios, como con
datos reales de una base. Este tipo de evaluaciones suele consumir muchos recursos, en especial
cuando se hacen pruebas de stress sobre los servidores para conocer los lmites de prestacin del
mismo.
Existen herramientas especficas en Postgresql para la efectivizacin de este tipo de tests, entre
ellos el ms popular es PgBench. Sin embargo, y gracias al auge de los lenguajes de scripting, es
muy sencillo disear un bench que incluya las particularidades de nuestro sistema.
PgBench requiere primero una creacin de una relacin (pgbench_branches), por lo que el
primer comando a ejecutar es 'pgbench -U<usuario> -i <base>' . Luego, simplemente quitamos la
opcin -i. Podemos indicar cantidad de conexiones (-c num), forma de comprometer una consulta (-
M [extended|simple|prepared]), cantidad de transacciones por cliente (-t num), duracin en
segundos (-T num_segundos), entre otras.
Existe otra herramienta (benchmark.py), la cual esta disponible de manera totalmente libre en
nuestro track (desarrollos.siu.edu.ar/trac/postgresql).
Las herramientas de benchmark permiten conocer las capacidades de transacciones por un

lapso de tiempo en nuestros servidores. Es muy util para cuando queremos modificar valores de
configuracin del motor o el servidor en general y queremos comprobar su repercusin.
Para hacer ms legible el presente documento, dividiremos el monitoreo de los procesos desde
el SO y desde la base, as como tambin las herramientas especficas para cada plataforma.
Es recomendable, que los monitoreos en sistemas en produccin sean constantes, pero no

intrusivos (a menos que una situacin en especial lo requiera).
Con respecto a los tests, utilizaremos unidades de testeo con herramientas propias de
Postgresql.
Monitoreando en plataformas Linux o Unix compatibles

Herramientas Previas
Existen una serie de comandos de los que el usuario debe estar familiarizado con su salida:
ps
lsof
free
iostat
mpstat
sar (si lo tiene)
htop o top
vmstat
/etc/init.d/postgres status o service postgres status (de acuerdo a la distribucin)
netstat
pgrep
awk y perl (bsico)
Tuberas y redirecciones.
Permisos de usuarios (muchas veces si el usuario no tiene permisos, no podr ver los
procesos)
Comandos
Podemos empezar por verificar que el servidor este corriendo actualmente:
Esto indica que el servidor est corriendo. Si observamos en ms detalle nos esta diciendo:
El PID 4526 nos est informando el proceso principal que se abri contra el cluster. Tambin
nos esta informando la ruta de la ubicacin fsica del PGDATA.
El PID 4622 es el proceso de escritura sobre la base.
El PID 4623 es el proceso que escribe sobre la WAL.
El PID 4624 es el proceso de autovacuum y el 4625 es el recolector de estadsticas. Estos
dos procesos puede ser desactivados, pero no es recomendable hasta el momento.
El PID 4739 es un cliente abierto. Nos est indicando tambin sobre que base y que usuario
se estn utilizando. Incluido a esto, tambin nos informa que se est accediendo localmente.
Viendo ms de cerca los procesos, podemos aadir mayores opciones al comando 'ps', para que
nos muestre informacin ms detallada.
# ps u C postgres C postmaster
Esto nos dar informacin ms precisa y extensa, lo que incluye el tiempo de consumo en CPU.
Los parmetros C permiten filtran por ocurrencias (postmaster es un alias que qued por
compatibilidad con versiones anteriores y se suele utilizar para identificar la conexin al PGDATA).
Adems este comando nos permite hacer cosas algo ms avanzadas como por ejemplo:
# ps f -o pid,ppid,args -C postgres -C postmaster

Esto permitir visualizar en forma de arte ascii, los procesos padre (PPID) y sus hijos (PID).
Vamos a ir un paso ms all de los procesos. Una de las cosas ms importantes que debemos
saber es a que archivos est accediendo un determinado proceso. En el ejemplo siguiente, se decidi
obtener el listado de todos los archivos que estn siendo accedidos por el proceso de escritura WAL.
Se le aadi un filtro 'head' para fines de legibilidad.
En el caso de necesitar conocer la cantidad solamente, debemos agregar | wc -l .
Saber cuantos archivos consume el servidor de base de datos es importante para tener en cuenta
el parmetro del kernel (maxfiles, openfiles). Este parmetro establece el mximo de archivos
abiertos. Esto es de suma importancia en ambientes crticos.
Una de las formas con la que podemos saber cuantos archivos est accediendo el servidor
postgres, es tecleando:
# lsof | perl -lane 'if (/postgres|postmaster/) {print $F[1]}' | wc -l
Esto es simplemente el total de ocurrencias que filtra la expresin regular de Perl. Esta lnea no
es lo suficientemente inteligente como para diferenciar entre distintos clusters (recordar que
podemos tener dos clusters en una mquina, lo que el conteo debera hacerse por separado).
Mejorando la lnea anterior podemos obtener la cantidad de procesos activos en un determinado

momento a fin de crear estadsticas de conexiones. Simplemente deberemos aadir la siguente lnea
de comando en el cron del sistema y este se encargar de loguear las ocurrencias.
# ps -A | egrep '(postgres|postmaster)' | wc -l | xargs echo `date +%Y%m%d%H%M ` >> /stat
En el cron simplemente podremos establecerlo para correr cada 20 o 10 minutos de acuerdo a

nuestras necesidades:
*/10 * * * * root <comando>
Haciendo el siguiente anlisis conoceremos el valor ms alto de procesos simultneos:
# awk '{print $2}' < /stat | sort -u | head -1
Debemos tener en cuenta que hay procesos que son netamente del servidor, por lo que no son
conexiones clientes.
Una de las cosas que ms afecta el rendimiento de las bases de datos, son los procesos I/O. Por
lo tanto, cuanto ms logremos disminuir la latencia en estos procesos, menores sern los tiempos de
respuesta. Es por eso que siempre es recomendable configurar un RAID para una base de datos.
La herramienta iostat no permitir ver las estadsticas de escritura y lectura en disco. Puede que
algunas versiones de Linux no incluyan las herramientas de stat, por lo que debemos instalarlas
ejecutando:
# apt-get install sysstat
Para hacerlo ms dinmico se recomienda utilizar el modo continuo de iostat (-d) la

herramienta 'watch':
# iostat d 2
La salida de dicho comando se puede apreciar en la siguiente imagen:
De este grfico podemos observar que: el servidor tiene 3 discos (de los cuales 1 es el que est
siendo escrito), el porcentaje de iowait (es la espera para poder escribir y leer y a mayor porcentaje,
indicar necesidad de contar con ms recursos en almacenamiento separados o RAID).
Si bien iostat y lsof son comandos muy tiles, puede que no sean tan intuitivos a primera vista.
Existe una herramienta en particular que es muy sencilla y que permite ver los recursos consumidos
en I/O por proceso. Es iotop, una herramienta desarrollada en Python y pueden encontrarla en su
sitio web http://guichaz.free.fr/iotop. Esta herramienta requiere que tengamos Python, kernel
superior a 2.6 e instalado el paquete python-pkg-resources (en debian y derivados). Requiere
adems algunos parmetros en el kernel activados.
Cuando el servidor se queda sin memoria o el proceso de postgres requiere ms memoria RAM
de la que el SO le puede otorgar a las aplicaciones, el SO comienza a 'swapear' (anglicismo que
indica que se comenz a utilizar el archivo de intercambio para trabajos que no pueden ser
ejecutados en RAM por falta de espacio o cuota asignada). Este mecanismo, por lo general, arroja
muy malos tiempos de respuesta por lo que debemos evitar en todo momento que el servidor se vea
obligado a 'swapear'.
Los comandos free y vmstat nos permitirn ver el espacio libre de memoria RAM y el uso de la
particin virtual o Swap.
La imagen anterior fue ejecutada con el comando 'free ; vmstat 1 1'. Se recomienda utilizar
watch para que muestre los resultados de manera constante y dinmica.
Del primer prrafo del resultado del comando anterior, nos interesa la lnea 'Swap'. Si
verificamos el valor 'used' est en 0, por lo que indica que hasta el momento todos los procesos
estn usando la RAM.
Tambin vemos que el total de la memoria RAM es de 605000 MB, teniendo libres 308880.
EL segundo prrafo corresponde al comando 'vmstat', el cual nos indica que no hay actividad
en la swap (si 0, so 0).
Otra de las cosas que nos interesa saber es la actividad del procesador. El comando para esto es
'mpstat'.
Es recomendable, utilizar 'top' o 'htop' para un resumen de lo ms importante de todos estos

comandos. Ambas herramientas no estn en todos los sistemas unix-like, por lo que es
recomendable conocer las herramientas estndar.
Tanto top como htop son muy amigables, por lo que no deberan tener mayores inconvenientes
en la lectura de sus resultados.
En el caso de top es aconsejable que cuando se despliegue la ejecucin, utilizar la ayuda

(presionando h) para poder adaptarlo a lo que queremos observar con ms detalle. Por ejemplo: Si
queremos desplegar la informacin del tamao por proceso en el archivo de intercambio y en
memoria, debemos presionar f (agrega columnas) y luego P y S.
Verificando la apertura del servidor a la red
Hemos configurado el servidor para que pueda escuchar sobre el puerto 5432, pero adems le
establecimos que pueda escuchar desde otro host (esto ltimo agrega que el puerto no slo esta
creado sino habilitado para recibir y comunicarse con otros clientes en otras terminales).
En esta imagen apreciamos que el servidor tiene abierto el socket correspondiente.
La forma manual de investigar acerca de los procesos es buscando dentro de la carpeta /proc.
En dicha carpeta encontraremos, por PPID, la informacin de cada proceso.
Por ejemplo:
cd /proc && pgrep '(postgres|postmaster)' | awk '{print $NF"/stat"}' | xargs cat
Esta lnea de comando simplemente muestra los contenidos del archivo stat dentro de cada
directorio de /proc/<pid>.
Para conocer el contenido de los archivos de /proc, lea el link [1] que se adjunta al final de la
documentacin.
Otra de las tareas importantes es monitorear el espacio libre que queda en el disco. Si el disco
se llena, los datos no se corrompern pero el servidor entrar en el estado PANIC y caer, por lo que
es muy til tener en cuenta o monitorear constantemente estos valores, en especial si utilizamos
PITR o particiones separadas para los archivos de la WAL.
El comando df h nos mostrar todas las particiones montadas y el espacio que se est
utilizando de cada una de ellas. Para saber el tamao actual del directorio que contiene los archivos
de la WAL podemos utilizar du h /ruta/a/la/WAL.
Monitoreando en sistemas Windows

La monitorizacin en sistemas Windows se puede hacer desde el Administrador de Tareas.
Existen otras herramientas privativas y libres para la medicin estadstica de los recursos.
Desde la lnea de comando podemos utilizar netstat, tasklist (similar al ps de unix-

compatibles).
Utilizando herramientas propias de PgFoundry y nativas del
paquete oficial
Como suele ser recomendable, las herramientas especficas de un determinado aplicativo
suelen ser ms explcitas que las estndares.
Sin utilizar herramientas externas a la empaquetacin oficial (dentro de la cual incluiremos

PgAdmin III), se puede monitorear la base a travs de logs y consultas intensivas al catalogo. De
ah, que es necesario tener establecida la variable de recoleccin de estadsticas activada
(track_activities).
Como otra recomendacin, se encuentra elevar el valor por defecto de la variable del motor
default_statistics_target. Un valor recomendado para un servidor en produccin es superior a 100.
Luego de eso, se puede establecer un nmero mayor o menor de acuerdo a la importancia de la
tabla.
En cuanto a los logs, por lo general, en un sistema en produccin variarn de acuerdo a una
situacin en especial. El nico recaudo a tener es que a medida que el nivel de mensajes que se
almacenan son ms detallados y a valores ms bajos (DEBUG[1-5]) ms sobrecarga a nivel de
procesamiento y mayor espacio de almacenamiento se ver afectado. Por ello, siempre se
recomienda que el almacenamiento de logs se haga separado del almacenamiento de la base y los
servidores de aplicacin. Esto adems permite que el sistema de ficheros a utilizar sea el ms
sencillo (caso ext2-3, FAT).
La herramienta ms popular para el anlisis de logs en Postgres es PgFouine. Ms detalle en la

seccin 'Archivado de Logs'.
Iopp es una herramienta desarrollada en postgres que sirve para medir las estadsticas de i/o
por proceso (http://git.postgresql.org/gitweb?p=iopp.git;a=blob_plain;f=iopp.c;hb=HEAD).
Requiere ser compilada con gcc, las indicaciones se hallan en el mismo rbol del git. Asimismo, se
requiere tener compilado el kernel de linux con el soporte para el archivo /proc/<pid>/io. Nuevas
versiones de kernel, soportan esta opcin de manera automtica.
Otra herramienta sencilla de instalar es pgstat. Desarrollada en python, puede ser descargada
del PgFoundry y slo requiere descomprimir y ejecutar, indicando a travs de parmetros la base y
el usuario. Est en versin beta an, pero es utilizable. Personalmente realic algunas
modificaciones en este aplicativo, pueden escribirme al mail personal en caso de estar interesados
(ya que al momento de escribir este documento, los cambios no fueron aprobados an por el autor).
La herramienta grfica ms estable para el monitoreo es PgAdmin. Para acceder a esta opcin
debemos ir al men Tools->Server Status. Ah podremos ver la actividad de las conexiones, los
bloqueos y las transacciones. Desde all mismo podremos seleccionar backends y cancelar sus
consultas o terminarlos. Se puede establecer inclusive el intervalo en segundos.
Existe una herramienta que recientemente adhiri un plug-in para recoleccin de estadsticas
(collectd). En el momento que se escribi este documento la ltima versin es la 4.8.0. Para
descargar la misma utilizamos wget:
# wget http://ipv4.collectd.org/files/collectd-4.8.0.tar.gz
# gzip d collectd-4.8.0.tar.gz
# tar xvf collectd-4.8.0.tar
Le recomiendo leer el link [2] para obtener detalles ms avanzados de cmo configurar este
servicio. Para la compilacin se necesita el compilador gcc y las libreras libdbd-pg-perl y libperl-
dev, asi como las libreras por estndar de gcc. Cuando ejecutemos ./configure (que por defecto
tratar de compilar con todos los plugins), debemos verificar que la lnea postgresql yes est en la
salida. Caso contrario puede que aparezca un dependency failed o un error que no permita su
compilacin.
Para la visualizacin del resultado de collectd, necesitamos la herramienta rrdtool (instalable

con apt-get install).
Ms all de las herramientas disponibles para la monitorizacin en caliente de la base de

datos, otro mtodo de monitoreo es utilizando el catalogo.
Las tablas-vistas que nos proveen informacin de escritura y lectura de bloques son:
pg_stat_*
pg_statio*
Las consultas sobre el catlogo se realizan a travs de SQL, y slo debemos considerar que
existen tipos de datos especficos para la relacin entre las mismas (OID).
Asimismo poseemos funciones especiales para la administracin de los backends, desde al base
de datos, permitiendo as, una administracin ms cabal simplemente desde cualquier cliente.
Seguidamente veremos algunas de las posibles consultas tiles al catalogo
Contabilizar conexiones:
SELECT count(*) FROM pg_Stat_activity;
Verificar hace cuanto se esta ejecutando la ltima consulta de un backend:
SELECT (now() - query_start) as tiempo_query,

backend_start as back_vivo_desde,
current_query as query,
usename as usuario
FROM pg_stat_activity;
Commits y rollbacks por cada base:
SELECT datname, xact_commit, xact_rollback

FROM pg_Stat_database;
Sumarizacin de consultas DML:
SELECT SUM(n_tup_ins),
SUM(n_tup_upd), SUM(n_tup_del)
FROM pg_stat_all_tables;
Sumarizacin de los planes:
SELECT SUM(seq_scan),
SUM(seq_tup_read), SUM(idx_scan),
SUM(idx_tup_fetch)
FROM pg_Stat_all_tables;
Visualizar bloqueos:
SELECT mode, count(mode)

FROM pg_locks
GROUP BY mode ORDER BY mode;
Sumarizacin de I/O en bloques (bloques son de 8k), si desea saber en cantidad de Kb,
multiplique por 8:
SELECT SUM(heap_blks_read) * 8
FROM pg_statio_user_tables;
SELECT SUM(idx_blks_read)
SELECT SUM(toast_blks_read)
SELECT SUM(tidx_blks_read)
Tamao de las bases:
select pg_database_size(name);
select pg_tablespace_size(name);
Ver consultas actuales corriendo:
SELECT pg_stat_get_backend_pid(s.backendid)
as procpid,
pg_stat_get_backend_activity(s.backendid)
as current_query
FROM
(SELECT pg_Stat_get_backend_idset()
as backendid) AS s;
Uso de disco (cada pgina es tpicamente de 8k):

SELECT relfilenode, relpages
FROM pg_class
WHERE relname = 'tabla';
Uso del disco para Toast:
SELECT relname, relpages

FROM pg_class ,
(SELECT reltoastrelid
FROM pg_class
WHERE relname = 'tabla') ss
WHERE oid = ss.reltoastrelid
OR oid = (SELECT reltoastidxid
FROM pg_class WHERE oid = reltoastrelid)
ORDER BY relname;
Para indices:
SELECT c2.relname, c2.relpages

FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'customer'
AND c.oid = i.indrelid
AND c2.oid = i.indexrelid
ORDER BY c2.relname;
Encontrar las tablas e ndices ms grandes (tambin se puede multiplicar x 8):

FROM pg_class
ORDER BY relpages DESC;
Monitorear estado de las tuplas por esquema (preferentemente utilice la opcin \x en psql):
SELECT schemaname ,
sum(seq_scan) as Seq_Scan,
sum(seq_tup_read) as Tuplas_seq_leidas,
sum(idx_scan) as Indices_scaneados ,
sum(idx_tup_fetch) as tuplas_x_indices_fetchs,
sum(n_tup_ins) as tuplas_insertadas, sum(n_tup_upd) as tuplas_actualizadas,
sum(n_tup_del) as tuplas_borradas,
sum(n_tup_hot_upd) as tuplas_actualizadas_hot,
sum(n_live_tup) as tuplas_vivas,
sum(n_dead_tup) as tuplas_muertas
FROM pg_stat_all_tables
WHERE schemaname !~ '^pg.*'
GROUP BY schemaname;
La siguiente consulta obtiene los datos necesarios para calcular los accesos a disco, tambin
podremos obtener una sumarizacin de las tuplas vivas y muertas de toda la base:
SELECT
max(xact_commit) as commits,
max(xact_rollback) as rollbacks,
max(blks_read)::text
|| '/' || (max(blks_read)*8)::text || 'kbs'
as bloques_leidos,
max(blks_hit),
max(numbackends) as numbackends,
sum(seq_scan) as seq_scans,
sum(seq_tup_read) as seq_tup_reads,
sum(idx_scan) as idx_scans,
sum(idx_tup_fetch) as idx_fetchs,
sum(n_tup_ins) as tup_ins,
sum(n_tup_upd) as tup_upds,
sum(n_tup_del) as tup_dels,
max(c.locks) as locks,
max(d.sess) as active,
sum(k.dead) as dead_tup,
sum(k.live) as live_tup
FROM pg_stat_database a, pg_stat_user_tables b,
(SELECT xp.n_dead_tup as dead,
xp.n_live_tup as live
FROM
(SELECT c.relname as nombre
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_roles r
ON r.oid = c.relowner
LEFT JOIN pg_catalog.pg_namespace n
ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
AND n.nspname <> 'pg_catalog'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
) xx JOIN pg_stat_all_tables xp
ON xx.nombre = xp.relname
) k,
(SELECT count(*) as locks from pg_locks) c,
(SELECT count(*) as sess
WHERE current_query !~ '.*<IDLE>*') d
WHERE datname = '<nuestra_base>';
La vista pg_statio_user_tables contiene la informacin por relacin, por lo que si queremos

visualizarla deberemos filtrar a travs del campo relname o schemaname. Anteriormente mostramos
algunos ejemplos con esta vista.
La vista pg_stats, contiene las estadsticas por columna, por lo que filtraremos por tabla.
Una consulta como la siguiente:
SELECT tablename, attname, avg_width,

n_distinct, most_common_vals,
most_common_freqs,
histogram_bounds, correlation
FROM pg_Stats
WHERE tablename !~ '^(pg|sql)';
Arroja:
Esta vista contiene los datos de cada columna, y es importante ya que nos indicar la frecuencia
de determinados valores en las columnas, pudiendo inferir directamente en el plan de ejecucin. El
caso ms comn es cuando un valor determinado tiene una frecuencia superior a 0.3, en cuyo caso
el planeador preferir accesos por Seq_scan debido a la repeticin de datos.
Esta vista utiliza los valores de la tabla pg_statistic y es mucho ms accesible que esta ultima
en trminos de consultas.
La vista pg_stat_user_tables posee la siguiente estructura:
Esta vista nos puede mostrar el estado de cada relacin, incluidos sus ltimos mantenimientos,
tuplas actualizadas, estimacin de tuplas muertas y vivas, etc.
Tambin poseemos las vistas para los ndices, que nos pueden indicar cuales son los ndices
ms utilizados o, lo que es ms til, los menos utilizados (pg_stat_user_indexes,
pg_statio_user_indexes).
Existen una serie de variables que mejoran la recoleccin de estadsticas (adems obviamente
de realizar usualmente ANALYZE a la base).
Hay una serie de variables que influyen en la recoleccin de estadsticas. track_activities

(recoleccin de estadsticas por sesin) , track_counts (recoleccin de estadsticas por base) y
update_process_title (muy til si realizamos mucho monitoreo desde consola del sistema operativo,
actualiza el ttulo del proceso de acuerdo a la consulta ) son las principales y por defecto vienen
activadas. Posiblemente si tenemos servidores de testeo o desarrollo, queramos desactivarlas para
evitar recoleccin de estadsticas en mquinas que corren varias aplicaciones y que no tienen un rol
crucial en el resultado.
Existen otras variables que pueden ser de utilidad tambin: log_parser_stats, log_planner_stats,
log_executor_stats y log_statement_stats. Por defecto estn en off. Las variables al ser activadas
acarrean mayor necesidad de procesamiento del recolector, por lo que afectan directamente al
rendimiento del servidor. Si log_statement_stats est en on, las otras deben estar en off, debido a
que esta contiene las otras. El resto son configuraciones por mdulo.
Esta opcin genera bastante overhead, as que es recomendable activarla cuando estamos en
proceso de afinamiento de determinadas consultas o del servidor.
Otra de ellas es default_statistics_target, por defecto est en un valor de 10, pero en produccin
se recomienda un valor de 100 en produccin.
Archivado de Logs
Los archivos de logs suelen ser molestos porque consumen ms I/O a medida que necesitamos
ms nivel de informacin.
Sin embargo, tenerlos bajo control es indispensable ya que son los nicos testigos de un error o
una situacin a la que posiblemente no podamos reproducir fcilmente en un ambiente aislado.
Si vistamos el postgresql.conf observaremos ua serie de variables especiales para esta tarea:
log_destination: este valor indica a que salida van dirigidos los mensajes.
logging_collector: necesario habilitarlo si queremos capturar los mensajes
log_directory: directorio en el cual almacenaremos los logs.
log_filename: nombre del archivo de log. Este podr utilizar un formato compatible con
POSIX (%Y=ao, %m= mes, %d=da , etc.)
La rotacin de un log, es la accin de llegar a un lmite establecido y empezar a loguear en un archivo vaco o nuevo.
log_truncate_on_rotation: esto borrar el contenido de un log cuando sucede la rotacin. No es

recomendable para ambientes de produccin.
log_rotation_age y log_rotation_size: indican cada cuanto se deber realizar la rotacin de los

logs.
log_min_messages: esto indica el nivel de logueo.
log_line_prefix: esta variable indica como va a estar formateada la salida del log. PgFouine
requiere que establezcamos esta variable para analizar el log.
log_statement: esto indica que tipo de sentencias irn al log (ddl, mod, all).
Tal como dijimos antes, la herramienta ms popular de revisin de logs es PgFouine. Est
escrito en PHP, por lo que requiere la instalacin del paquete php5-cli (Debian y derivados).
La desventaja que tiene PgFouine es que requiere tocar la salida de los logs, por lo que al
principio puede parecer incomodo.
PgFouine tiene varias opciones, las que podremos ver ejecutando 'pgfouine.php' en la linea de
comando. La ejecucin bsica seria : 'pgfouine.php -file <archivo_log> -logtype stderr'. La opcin
logtype deber corresponder a la que tenemos en el postgresql.conf (log_destination). Previo a esto
debemos preformatear la salida (log_line_prefix) a: '%t [%p]: [%l-1] ' si utilizamos stderr.
Monitorizacin6
Contenido
[ocultar]
1
Introducci
n
2 Saber si
la base de
datos esta
en marcha
3 Usando
herramient
as
estandard
de Unix
4
Determina
ndo el uso
de disco
4.1
Ejemplos
5 Saber los
usuarios
conectados
6
Estadstica
s
6.1
Configurac
in de la
recoleccin
de
estadsticas
6.2
Visualizar
las
estadsticas
7
Visualizaci
n de locks
8 Ver los
ficheros de
log
9 Tablas de
sistema
Introduccin
A continuacin describimos las tareas bsicas de monitorizacin del agente de base de datos PostgreSQL.
Saber si la base de datos esta en marcha

Para saber si la base de datos esta en marcha debemos conectarnos al servidor de base de datos con un
usuario reconocido y ejecutar
pg_ctl status
pg_ctl: el servidor est en ejecucin (PID: 4567)
C:/Archivos de programa/PostgreSQL/8.2/bin/postgres.exe "-D" "C:/Archivos de
programa/PostgreSQL/8.2/data"
Como vemos el mensaje que nos muestra es que el sistema esta el servidor est en ejecucin.
Si el sistema no estaria inicializado nos daria el siguiente mensaje
pg_ctl: no hay servidor en ejecucin
Usando herramientas estandard de Unix

El comando estandard psde Unix permite inspeccionar los procesos incializados por el servidor postgres
en la mqiuna:
-bash-3.2$ ps auxww | grep ^postgres

postgres 30390 0.0 0.0 46984 1500 ? Ss Nov23 0:00 postgres: logger
process
postgres 30392 0.0 0.8 87024 36320 ? Ss Nov23 0:01 postgres: writer
process
postgres 30393 0.0 0.0 86032 1764 ? Ss Nov23 0:00 postgres: wal
writer process
postgres 30394 0.0 0.1 89536 4844 ? Ss Nov23 0:20 postgres:
autovacuum launcher process
postgres 30395 0.0 0.0 49040 1468 ? Ss Nov23 0:00 postgres: archiver
process last was 000000010000000400000009
postgres 30396 0.0 0.1 52136 4096 ? Ss Nov23 1:21 postgres: stats
collector process
En el ejemplo anterior se puede ver cmo postgres esta actualmente recogiendo estadsticas,lanzando el
procedo vacuumm, etc...
Determinando el uso de disco

Cada tabla tiene un archivo primario en el disco dnde se guarda la mayoria de los datos. Si una tabla
tiene alguna columna que puede ser potencialmente muy grande, existe tambin un archivo TOAST
asociado con la tabla, que es usado para guardar valores grandes que no caben en la tabla principal. Se
crear un ndice para cada tabla TOAST.
Se puede monitorear el espacio end disco mediante funciones SQL, medinate la informacin de VACUUM
o mediante las herramientas en contrib/tools de la carpeta de la instalacin de postgres.
Ejemplos
Visualizar el uso de disco de cualquier tabla:
SELECT relfilenode, relpages FROM pg_class WHERE relname = 'capuntes';

relfilenode | relpages
-------------+----------
55304 | 172
(1 row)
Tpicamente cada pgina es de 8 kilobytes.

Visualizar el espacio ocupados por las tablas TOAST:

FROM pg_class,
(SELECT reltoastrelid FROM pg_class
WHERE relname = 'gven_promocr') ss
WHERE oid = ss.reltoastrelid
OR oid = (SELECT reltoastidxid FROM pg_class
WHERE oid = ss.reltoastrelid)
ORDER BY relname;
relname | relpages
----------------------+----------
pg_toast_70827 | 0
pg_toast_70827_index | 1
(2 rows)
Visualizar el tamao de los ndices de una tabla:
SELECT c2.relname, c2.relpages

FROM pg_class c, pg_class c2, pg_index i
WHERE c.relname = 'cterdire'
AND c.oid = i.indrelid
AND c2.oid = i.indexrelid
ORDER BY c2.relname;
relname | relpages
-------------+----------
f_cterdire1 | 2
f_cterdire2 | 2
f_cterdire3 | 2
f_cterdire4 | 2
f_cterdire5 | 2
f_cterdire6 | 2
i_cterdire1 | 2
p_cterdire | 2
Visualizar las tablas y los ndices ms grandes:
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;

relname | relpages
------------------------------------+----------
table_test | 352969
p_test | 61076
pg_toast_81538 | 2833
pg_attribute | 1055
cmunicip | 1038
gtpv_logterm | 933
....
Saber los usuarios conectados
En postgres existe una vista que nos muestra los usuarios conectados al sistema. Nos conectamos al
servidor postgres e ingresamos al psql.
psql -h localhost -p 5432 postgres postgres

postgres=# SELECT * FROM pg_stat_activity;
datid | datname | procpid | usesysid | usename | current_query | waiting

| query_start | backend_start |
client_addr | client_port
-------+----------+---------+----------+----------
+---------------------------------+---------+----------------------------
+----------------------------+-------------+-------------
10819 | postgres | 1800 | 10 | postgres | <IDLE> | f
| 2007-09-10 12:41:00.765+02 | 2007-09-10 12:39:39.64+02 | 127.0.0.1
| 1054
10819 | postgres | 1736 | 10 | postgres | select * from pg_stat_activity;
| f | 2007-09-10 12:46:20.859+02 | 2007-09-10 12:45:24.406+02 | 127.0.0.1
| 1056
(2 filas)
En la tabla nos muestra los usuarios conectados, los select ejecutados, la terminal, el puerto, etc.
Estadsticas
El statistics collector de Postgres s un subsistema que permite la recoleccin y presentacin de
informes sobre la actividad del servidor.
Actualmente, el recolector de estadsticas puede El collector puede realizar las siguientes tareas:
Contar accesos a tablas e ndices em trminos de filas individuales o en bloques de disco.
Seguimiento del nmero de filas en cada tabla, y las horas de los timos vacuum y analyze para cada
tabla.
Contarel nmero de llamdas a las user-defined functions y el tiempo total empleado en cada una.
Determinar el comando exacto que est siendo ejecutando por otro servidor.
Configuracin de la recoleccin de estadsticas

Puesto que la recopilacin de las estadsticas, aade algo de sobrecarga en la ejecucin de las consultas,
el sistema puede ser configurado para que recoger o no recoger las estadsticas. sta es controlada por
los parmetros de configuracin fijados en el fichero en postgresql.conf:
track_counts controla si se recogen estadsticas sobre los accesos a tablas e ndices.
track_functions activa el seguimiento de uso de las user-defined functions.
track_activities activa la monitorizacin del comando siendo ejecutado actualmente por qualquier
srrvidor
Normalmente, estos parmetros se establecen en postgresql.conf para que se apliquen a todos los
procesos del servidor, pero es posible activar o desactivar los parmetros en sesiones individuales con el
comando SET.
Visualizar las estadsticas

Existen vistas predefinas, como las de la tabla de a contiuacin que muestran los resultados de la
recogida de estadstcas. Al usar las estadsticas para supervisar la actividad actual, es importante darse
cuenta de que la informacin no se actualiza instantneamente. Cada proceso individual transmite los
datos estadsticos justo antes de finalizar el proceso, de modo que una consulta o transaccin en curso no
afecta a la muestra de totales en las estadticas.
Nombre de
Descricin
la vista
pg_stat_ac Una lnea para cada proceso, que muestra la base de datos OID, el nombre de base de
tivity datos, la ID del proceso, el usuario OID, el nombre de usuario, la consulta actual, el
estado de espera de consulta, la hora en que la transaccin y la consulta actual se
iniciaron, hora en que se inici el proceso, la direccin del cliente y nmero de
puerto. Las columnas que se presentan los datos sobre la consulta actual estn
disponibles a menos que el parmetro track_activities haya sido desactivado.
Adems, estas columnas son slo visibles si el usuario que examina la vista es un
super-usuarioel usuario propietario del proceso que presenta.
Una fila nica, mostrando las estadsticas de todo grupo del background writer: el
nmero de checkpoints previstos, checkpoints pedidos, buffers escritso por los
checkpoints y loas escanners de limpieza y el nmero de veces background writer
pg_stat_bg
deteuvo un escanner de limpieza porque haba escrito demasiados bfferes. Tambin
writer
incluye estadsticas sobre el pool de buffers compartidos, incluyendo los buffers
escritos por backends (es decir, no por el background writer) y los buffers totales
asignados.
Una fila por base de datos, que muestra el OID de la base de datos , el nombre de
base de datos, el nmero de procesos activos del servidor conectado a la base de
pg_stat_da datos, el nmero de transacciones finalizadas y retrocedidas en esa base de datos, el
tabase total de bloques de disco ledos, y el total de buffers bloqueados (es decir, las las
solicitudes de lectura bloqueadas encontrando e bloque ya existente el buffer de la
cach), el nmero de filas devueltas, buscadas, insertadas, actualizadas y eliminadas.
Para cada tabla de la base de datos actual (incluyende tablas TOAST), el nmero oid
de la tabla, el esquema y el nombre de tabla, el mero de scans secuenciales
iniciados, el nmero de filas en vivo obtenidos por exploraciones secuenciales, el
nmero de ndice de exploraciones iniciadas (sobre todos los ndices que pertenecen a
la tabla ), el nmero de filas buscadas en directo por scans de ndices, el nmero de
pg_stat_all
filas inserradas, actualizadas y eliminadas, el nmero updates de filas que fueron
_tables
HOT (es decir, sin actualizacin por separado del ndice), el nmero de filas de vivas
y muertas, la ltima vez que se pas el porceso vacuum en la tabla manualmente,la
ltima vez que se pas el porceso vacuum en la tabla por demonio Autovacuum, la
ltima vez que fue analizada de forma manual, y la ltima vez que fue analizada por
el demonio Autovacuum.
pg_stat_sy
Igual que pg_stat_all_tables, a excepcin que slo se muestran las tablas de sistema.
s_tables
pg_stat_us
Igual que pg_stat_all_tables, a excepcin que slo se muestran las tablas del usuario.
er_tables
Por cada ndice en la base de datos actual, la tabla y el ndice OID, esquema,la tabla y
pg_stat_all el nombre del ndice, el nmero de ndice de index scan en ese ndice, el nmero de
_indexes registros retornados por los index scans, y el nmero de filas buscadas en vivo por
simples index scnas usando dicho ndice.
pg_stat_sy Igual que pg_stat_all_indexes, a excepcin que slo se muestran las ndices de las
s_indexes tablas de sistema
pg_stat_use Igual que pg_stat_all_indexes, a excepcin que slo se muestran los ndices de las
r_indexes tablas del usuario.
Para cada tabla de la base de datos actual (incluyendo tablas TOAST), el OID de la
tabla, esquema y nombre de la tabla, el nmero de bloques disco ledos de la tabla,
pg_statio_ nmero de visitas de bffer, el nmero de bloques de disco ledos y las visitas de
all_tables buffer de la tabla, el nmero de bloques de disco de ledos visitas de buffer de la tabla
TOAST auxiliar (si existe) y el nmero de bloques de disco ledos y las visitas al
buffer para el ndice de la tabla TOAST.
pg_statio_s Igual que pg_statio_all_tables, a excepcin que slo se muestran las tablas de
ys_tables sistema.
pg_statio_
Igual que pg_statio_all_tables, a excepcin que slo se muestran las tablas del
user_table
usuario.
s
Para cada ndice de la base de datos actual, el OID de la table y el ndice, el esquema,
pg_statio_
el nombre del ndice de la tabla y el ndice, el nmero de bloques de disco ledos y las
all_indexes
visitas al buffer para ste ndice.
pg_statio_s Igual que pg_statio_all_indexes, a excepcin que slo se muestran ndices de las
ys_indexes tablas de sistema.
pg_statio_
Igual que pg_statio_all_indexes, a excepcin que slo o se muestran ndices de las
user_index
tablas del usuario.
es
pg_statio_ Para cada objeto secuencia en la base de datos actual, el OID de la secuencia, el
all_sequen esquema y el nombre de la secuencia, el nmero de bloques de disco ledos y las
ces visitas al buffer en esa secuencia .
pg_statio_s Igual que pg_statio_all_sequences, a excepcin que slo se muestran secuencias del
ys_sequenc sistema. (Actualmente , no existen secuendias del sistema, por lo que la vista estar
es vaca)
pg_statio_
Igual que pg_statio_all_sequences, a excepcin que slo se muestran secuencias del
user_seque
usuario.
nces
Para todas las funciones monitorizadas, el OID de la funcin, el esquema, el nombre,
pg_stat_us
el nmero de llamadas,el tiempo total, el tiempo propio. El tiempo propio es la
er_functio
cantidad de tiempo empleado por la funcin por si misma, el total incluye el tiempo
ns
empleado en las funciones que llamdas. Los tiempos se presentan en milisegundos.
La vistas pg_statio_ sn bsicamente tiles para determinar la efectividad del buffer cache. Cuando el
nmero de lecturas de disco es mucho menor que el nmero de visitas a la cache, significa que la cache
esta leyendo satisfactoriamente la mayora de las consultas sin invocar una llamada al kernel.
Existe otra forma de acceder a las estadticas mediante llamadas a funciones que realizan consultas a las
mismas vistas comentadas en el punto anterior. Se puede obtener ms informacin sobre dichas
funciones en la Tabla 26-2. de la documentacin oficial de Postgres.
Por ejemplo, para obtener todas las consultas realizadas y su PID por todos los procesos del servidor:
SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,

pg_stat_get_backend_activity(s.backendid) AS current_query
FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
sta consulta retorna:
procpid | current_query
---------
+----------------------------------------------------------------------------------
----------------
15973 | <IDLE>
15974 | <IDLE>
21652 | SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
: pg_stat_get_backend_activity(s.backendid) AS current_query
: FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
21704 | <IDLE>
21755 | SELECT \r
: garticul.nomart, gcomforh.delega, gcomforh.depart,\r
: gcomforl.orden, gdeparta.reflec, gcomforl.codart,\r
: (SELECT MAX(codean)\r
: FROM gartiean\r
: WHERE gcomforl.codart = gartiean.codart\r
: AND gcomforl.varlog = gartiean.varlog\r
: AND gcomforl.udmcom = gartiean.coduni\r
: AND gartiean.estado = 'A') AS codean\r
:
: INTO TEMP tmp_impeti_1_0001\r
: FROM gcomforh\r
: INNER JOIN (\r
: gcomforl LEFT JOIN garticul ON gcomforl.codart =
garticul.codigo\r
: ) ON gcomforh.cabid = gcomforl.cabid\r
: INNER JOIN gdeparta ON gcomforh.delega = gdeparta.delega AND
gcomforh.depart = gdeparta.depart\r
: WHERE \r
:
: gcomforh.docser = '04'\r
:
: ORDER BY 1, 2, 3
21768 | <IDLE>
Visualizacin de locks
Otra herramienta til para monitorizar la actividad de la base de datos es la tabla de sistema pg_locks.
Permite al administrador de la bbdd ver los bloqueos que provocan transacciones abiertas.
La tabla contiene una fila por lock active, modo de lock solicitado i transaccin. Para ms informacin,
visitar la documentacin
Ver los ficheros de log

En el directorio $PGHOME/data/pg_log el sistema deja los ficheros de logs. Cada vez que el sistema se
reinicializa crea un nuevo fichero de log.
2007-09-10 09:20:03 LOG: database system was shut down at 2007-09-06 13:33:43 Hora
estndar romance
2007-09-10 09:20:03 LOG: checkpoint record is at 0/DB50088
2007-09-10 09:20:03 LOG: redo record is at 0/DB50088; undo record is at 0/0;
shutdown TRUE
2007-09-10 09:20:03 LOG: next transaction ID: 0/262151; next OID: 221208
2007-09-10 09:20:03 LOG: next MultiXactId: 1; next MultiXactOffset: 0
2007-09-10 09:20:03 LOG: database system is ready
2007-09-10 09:21:29 ERROR: syntax error at or near "nomtra" at character 938
2007-09-10 09:21:29 STATEMENT: --
***********************************************************************************
*
-- DEISTER WebStudio XSQL-SELECT Mon Sep 10 09:21:30 CEST 2007 Engine: postgres
--
***********************************************************************************
*
SELECT
capuntes.oid AS rowid,
capuntes.apteid, capuntes.fecha, capuntes.asient, capuntes.orden,
capuntes.jusser, capuntes.docser, capuntes.proyec, cproyect.nompro,
capuntes.seccio,
cseccion.nomsec, capuntes.sistem, capuntes.diario, cdiarios.nomdia,
capuntes.cuenta,
ccuentas.nombre, capuntes.codaux, ccuentas.estado, capuntes.ctaaux,
cctaauxl.desval,
capuntes.codcon, cconcept.coment, cconcept.opedeb, cconcept.opehab,
capuntes.concep,
capuntes.debe, capuntes.haber, capuntes.divdeb, capuntes.divhab,
capuntes.moneda,
cmonedas.desmon, capuntes.cambio, capuntes.fecval, capuntes.contra,
ccuentas2.nombre nomtra, capuntes.origen, capuntes.punteo,
capuntes.loteid,
capuntes.cosaut,
capuntes.empcode, capuntes.dimcode1, capuntes.dimcode2,
capuntes.cantid1, capuntes.cantid2,
capuntes.user_created, capuntes.date_created, capuntes.user_updated,
capuntes.date_updated,
cempresa.empname, cempresa.divemp, cmonedas_loc.desmon desmon_loc,
ccuentas.tipcta, ccuentas.codaux cta_codaux, ccuentas.ctaper,
cenllote.tabname, cenllote.colname,
cproyect.seccio cproyect_seccio, ccuentas.tipact ccuentas_tipact,

ccuentas.activa ccuentas_activa,
cconcept.debhab cconcept_debhab, cconcept.activa cconcept_activa,
cconcept.obliga cconcept_obliga,
(CASE WHEN cconcept.debhab IS NOT NULL THEN cconcept.debhab ELSE

COALESCE(ccuentas.tipact, 'A') END) debhab,
(CASE WHEN (((ccuentas.activa LIKE '%I%' AND capuntes.codcon IS NULL)
OR
(ccuentas.activa LIKE '%I%' AND cconcept.activa LIKE
'%I%')
) AND (ccuentas.tipact = 'A' OR (ccuentas.tipact='D' AND
capuntes.debe != 0)
OR (ccuentas.tipact='H'
AND capuntes.haber != 0))
) OR cconcept.obliga LIKE '%I%' THEN 1 ELSE 0 END)
activa_i,
(CASE WHEN (((ccuentas.activa LIKE '%E%' AND capuntes.codcon IS NULL)
OR
(ccuentas.activa LIKE '%E%' AND cconcept.activa LIKE
'%E%')
capuntes.debe != 0)
) OR cconcept.obliga LIKE '%E%' THEN 1 ELSE 0 END)
activa_e,
(CASE WHEN (((ccuentas.activa LIKE '%C%' AND capuntes.codcon IS NULL)
OR
(ccuentas.activa LIKE '%C%' AND cconcept.activa LIKE
'%C%')
capuntes.debe != 0)
) OR cconcept.obliga LIKE '%C%' THEN 1 ELSE 0 END)
activa_c,
(CASE WHEN (((ccuentas.activa LIKE '%V%' AND capuntes.codcon IS NULL)
OR
(ccuentas.activa LIKE '%V%' AND cconcept.activa LIKE
'%V%')
capuntes.debe != 0)
) OR cconcept.obliga LIKE '%V%' THEN 1 ELSE 0 END)
activa_v
FROM capuntes
LEFT JOIN cproyect ON capuntes.proyec = cproyect.codigo
LEFT JOIN cseccion ON capuntes.seccio = cseccion.codigo
LEFT JOIN ccuentas ON capuntes.cuenta = ccuentas.codigo
LEFT JOIN cctaauxl ON capuntes.codaux = cctaauxl.codaux AND
capuntes.ctaaux = cctaauxl.ctaaux
LEFT JOIN ccuentas ccuentas2 ON capuntes.contra = ccuentas2.codigo
LEFT JOIN cmonedas ON capuntes.moneda = cmonedas.codigo
LEFT JOIN cdiarios ON capuntes.diario = cdiarios.codigo
LEFT JOIN cconcept ON capuntes.codcon = cconcept.codigo
LEFT JOIN cenllote ON capuntes.loteid = cenllote.loteid
LEFT JOIN (
cempresa LEFT JOIN cmonedas cmonedas_loc ON cempresa.divemp =
cmonedas_loc.codigo
) ON capuntes.empcode = cempresa.empcode
--
=================================================================================
-- Query condition ($0) + non xml security filters
--
=================================================================================
WHERE (1=1) AND (1=0)
2007-09-10 12:24:18 LOG: received fast shutdown request
2007-09-10 12:24:18 LOG: aborting any active transactions
2007-09-10 12:24:18 LOG: shutting down
2007-09-10 12:24:18 LOG: database system is shut down
2007-09-10 12:24:19 LOG: logger shutting down
Tablas de sistema
El esquema information_schema contiene informacin sobre todos los objetos definidos en una bbdd. A
continuacin se listarn las vistas presentes en el information esquema. Para ms detalles visitar la
Documentacin
information_schema_catalog_name
administrable_role_authorizations
applicable_roles
attributes
check_constraint_routine_usage
check_constraints
column_domain_usage
column_privileges
column_udt_usage
columns
constraint_column_usage
constraint_table_usage
data_type_privileges
domain_constraints
domain_udt_usage
domains
element_types
enabled_roles
foreign_data_wrapper_options
foreign_data_wrappers
foreign_server_options
foreign_servers
key_column_usage
parameters
referential_constraints
role_column_grants
role_routine_grants
role_table_grants
role_usage_grants
routine_privileges
routines
schemata
sequences
sql_features
sql_implementation_info
sql_languages
sql_packages
sql_parts
sql_sizing
sql_sizing_profiles
table_constraints
table_privileges
tables
triggers
usage_privileges
user_mapping_options
user_mappings
view_column_usage
view_routine_usage
view_table_usage
views
El esquema information_schema es el definido por el estandard SQL, y por tanto no contiene
informaccin relativa a caractersticas propias de Postgres. Estas caractersticas se encuentran las tablas
de catlogo del sistema:
Nombre de
Descripcin:
catlogo
pg_aggregate Las funciones de agregado
pg_am Mtodos de acceso de ndice
pg_amop mtodo de acceso de los operadores
pg_amproc mtodode acceso de los procedimientos
pg_attrdef valores por defecto de columna
pg_attribute columnas de la tabla (los "atributos")
pg_authid identificadores de autorizacin (roles)
pg_auth_members Identificador de las relaciones de autorizacin de miembros
pg_cast modelos (datos de las conversiones de tipos)
pg_class tablas, ndices, secuencias, puntos de vista (las "relaciones")
las restricciones de verificacin, limitaciones nicas, restricciones de clave
pg_constraint
principal, las restricciones de claves forneas
pg_conversion codificacin de la informacin de conversin
pg_database bases de datos dentro de esta base de datos de clster
pg_depend dependencias entre los objetos de base de datos
pg_description descripciones o comentarios sobre los objetos de bases de datos
pg_enum enum etiqueta y el valor de las definiciones
pg_foreign_data_wr
definiciones envoltura externa de datos
apper
pg_foreign_server definiciones de servidores externos
pg_index informacin adicional de ndices
pg_inherits jerarqua de herencia de mesa
pg_language Lenguajes para la escritura de funciones
pg_largeobject objetos de gran tamao
pg_listener apoyo a la notificacin asncrona
pg_namespace esquemas
pg_opclass mtodo de acceso de las clases de operador
pg_operator operadores
pg_opfamily mtodo de las familias el acceso del operador
pg_pltemplate templates a para las lenguas de procedimiento
pg_proc funciones y procedimientos
pg_rewrite Reglas de reescriturade consultas
pg_shdepend Dependencias de objetos compartidos
pg_shdescription los comentarios sobre los objetos compartidos
pg_statistic estadsticas planificador
pg_tablespace de tablas dentro de esta base de datos de clster
pg_trigger Disparadores
pg_ts_config configuraciones de bsqueda de texto
pg_ts_config_map asignaciones de seal configuraciones de bsqueda de texto '
pg_ts_dict diccionarios de bsqueda de texto
pg_ts_parser analizadores de bsqueda de texto
pg_ts_template bsqueda de plantillas de texto
pg_type tipos de datos
pg_user_mapping asignaciones de los usuarios a los servidores de extranjeros
Autenticacin del Cliente
Languages: English Espaol
Los usuarios permitidos para el establecimiento de la conexin a la base de datos son controlados por un archivo
sencillo en el directorio raz de su base de datos, llamado pg_hba.conf. En cuanto corre initdb para la creacin del
clster de la base de datos, es creado un fichero pg_hba.conf con los valores por omisin.
Los permisos que existen por omisin dependen de cmo fue invocado initdb. Por omisin, los nuevos clsters son
creados con el tipo trust con el cual, cualquier usuario local puede conectarse a la base de datos. Sin embargo, algunos
empaquetadores de PostgreSQL pueden cambiar esto. Por ejemplo, si usa 'service initdb' en Red Hat para crear el
clster, ste llama a initdb de la siguiente manera:
initdb --pgdata='$PGDATA' --auth= 'ident sameuser'
El cual usa el no particularmente popular mtodo ident para averiguar si un usuario est permitido conectarse, lo cual
suele ser frustrante para quienes no son conscientes de ello.
Una instalacin tpica recomendada para el acceso desde la red de la base de datos toma la direccin local LAN y slo
permite los clientes que se autentiquen usando una contrasea encriptada a travs de MD5. La siguiente entrada en en
el pg_hba.conf ilustrar algo como esto:
# TIPO BASE_DE_DATOS USUARIO CIDR-DIRECCIN MTODO
host all all 192.168.1.0/24 md5
Esto slo permite conectarse a los clientes con las direcciones IP de la red 192.168.1.0 -- 192.168.1.255 y slo si
proveen la contrasea correcta para el usuario. Observe que un acceso de la red como ste puede establecerse slo si
est permitido en el parmetro listen_addresses de postgresql.conf.
Las contraseas de los usuarios de la base de datos son aplicadas cuando se crea el usuario con CREATE ROLE y
pueden ser modificadas con la orden ALTER ROLE. createuser puede ser una herramienta muy til para ayudar en este
sentido.
Hay una pequea trampa aqu: puesto que para la creacin de un nuevo rol se requiere que la conexin a la base de
datos sea como un superusario, cmo se pueden empezar a crear usuarios? Un enfoque comn es comenzar con un
pg_hba.conf que confa slo a los usuarios que se conectan localmente:
# Slo conexiones locales para el socket de Unix
local all all trust
# IPv4 local connections:
Si la base de datos est configurada de esta forma, cualquiera logueado en el sistema puede ahora conectarse al
servidor a su voluntad, as que no desea conservar esta configuracin por mucho tiempo. Lo que puede hacer ahora es
usar la orden ALTER ROLE para asignar una contrasea fuerte al superusuario postgres. Una vez que lo haya hecho,
puede detener el servicio (pg_ctl stop), cambiar todos los "trust" por "md5", agregar su rango o bloque de red completo a
pg_hba.conf, y cambiar el parmetro listen_address de postgresql.conf. Cuando lo inicie nuevamente, ya tendr una
cuenta de superusuario de la cual conoce la contrasea, con la cual puede crear las cuentas para sus usuarios
regulares.
Contents
[hide]
1
Ejempl
os
1.1
Ejempl
o1
1.2
Ejempl
o2
1.3
Ejempl
o3
1.4
Ejempl
o4
2
Autenti
cacin
LDAP
3
Artculo
s
relacion
ados
Ejemplos
Ejemplo 1
Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde el ordenador con IP 10.0.0.100, y mtodo
de autentificacin md5:
host test001 test 10.0.0.100 255.255.255.255 md5
Esta misma entrada se podra escribir tambin con la mscara de red en notacin CIDR:
Ejemplo 2
Acceso por tcp/ip (red) a la base de datos test001, como usuario test desde todos los ordenadores de la red 10.0.0.0,
con mascara de red 255.255.255.0 (254 ordenadores en total) y mtodo de autentificacin md5:
host test001 test 10.0.0.0 255.255.255.0 md5
Esta misma entrada se podra escribir tambin con la mascara de red en notacin CIDR:
Ejemplo 3
Acceso por tcp/ip (red), encrptado, a todas las bases de datos de nuestro cluster, como usuario test desde el ordenador
con IP 10.0.0.100, y el ordenador 10.1.1.100 y mtodo de autentificacin md5 (necesitamos dos entradas en nuestro
fichero pg_hba.conf):
Ejemplo 4
Denegar el acceso a todos las bases de datos de nuestro cluster al usuario test, desde todos los ordenadores de la red
10.0.0.0/24 y dar acceso al resto del mundo con el mtodo md5:
host all test 10.0.0.0/24 reject
Autenticacin LDAP
Postgresql nos permite comprobar los usuarios contra un sistema LDAP, aunque si bien esto es posible, hay que tener
en cuenta que el usuario igualmente debe existir en la base datos.
Parmetros que hay que considerar al realizar una peticin de autenticacin a un servidor de LDAP:
Parmetros Descripcin
ldapserver IP o dominio del servidor ldap a conectarse.
ldapprefix El nombre de usuario.
ldapsuffix El sufijo que continua al nombre de usuario, que concluira para formar el dn.
ldapport Puerto al que se va a conectar al servidor ldap, en caso de no ser especificado se utiliza el
puerto por default, 389.
ldaptls Debe setearse en 1 si se quiere que la peticin de autenticacin hacia el servidor ldap se
realize utilizando encriptacin TLS.
Ejemplo del uso de la autenticacin LDAP:

host all all 127.0.0.1/24 ldap ldapserver="localhost" ldapprefix="uid=" ldapsuffix=",dn=testing-et,dc=com,dc=cu"
Programar Tareas
Contents
[hide]
1
General
idad
2
Crontab
2.1
Sintaxis
bsica
2.2
Editand
o
nuestro
fichero
crontab
2.3
Conteni
do de
un
fichero
crontab
2.4
/etc/cro
ntab
contien
e
instrucc
iones
para
que
cron
ejecute
los
scripts
de los
director
ios
3 At
3.1
Especifi
cacione
s
3.2
Opcion
es
Generalidad
Veremos como podemos configurar nuestro sistema operativo para realizar tareas peridicas de una manera muy
cmoda. Tenemos dos mecanismos bsicos para programar tareas:
-.crontab: nos permite programar tareas que queremos repetir de forma peridica.
-.at: nos permite realizar una tarea a una hora determinada pero slo una vez.
Crontab
El comando crontab (cron) nos permite programar tareas y/o ejecutar comandos peridicamente a ciertas horas, ciertos
das de la semana, del mes, del ao, etc. Con este comando, cada administradorBD puede definir sus propias tareas
programadas.
Sintaxis bsica
* crontab -l Mostrar las tareas programadas por el usuario.
* crontab -e Editar el fichero crontab. Con esto editaremos el fichero de configuracin de crontab de cada usuario
para poder modificar las tareas programadas.
* crontab -r Eliminar el fichero crontab corriente.
* crontab -u <usuario> Aplicar una de las opciones anteriores para un usuario determinado. Slo root puede
hacerlo.
El demonio cron ejecuta las instrucciones contenidas en:

* el archivo /etc/crontab (tables for cron).
* los archivos ubicados en el directorio /etc/cron.d
* los archivos /var/spool/cron/crontabs/<usuario>
Editando nuestro fichero crontab

gilbertoc@gilbertoc:~$ crontab -e
Contenido de un fichero crontab

Es similar a:
#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root cd / && run-parts --report /etc/cron.daily
47 6 * * 7 root cd / && run-parts --report /etc/cron.weekly
52 6 1 * * root cd / && run-parts --report /etc/cron.monthly
# Hacer una copia de seguridad del directorio documentos cada da a las 00:00
0 0*** tar -czf docs-`date -I`.tar.gz ~/documentos/
(el smbolo ~ es equivalente a $HOME, y a /home/usuario/)
# Hacer una copia de seguridad de la Base de datos cada da a las 07:30 y 21:30
30 7 * * 1-5 /var/respaldos/scripts/mantenimiento_postgresql.sh
30 21 * * 1-5 /var/respaldos/scripts/mantenimiento_postgresql.sh
* m: minuto [0-59].
* h: hora [0-23].
* dom: da del mes [1-31].
* mon: mes [1-12].
* dow: da de la semana [0-7] (0 7 es Domingo).
* user: usuario.
* command: comando.
A la hora de expresar los minutos, horas, das, meses y ao, podemos utilizar listas: 3,23,43; rangos de tiempo: 1-5;
pasos: 2-6/2 (= 2,4,6); y * (cualquier valor).
/etc/crontab contiene instrucciones para que cron ejecute los scripts de los
directorios
* /etc/cron.hourly
* /etc/cron.daily
* /etc/cron.weekly
* /etc/cron.monthly
Agregando una lnea para cada tarea que queramos programar. Podemos hacernos nuestros scripts y hacer que
crontab los ejecute para tener tareas programadas ms complejas.
En caso de necesitar reiniciar el servicio puede realizarlo:
gilbertoc@gilbertoc:~$ service crond restart
O
gilbertoc@gilbertoc:~$ /etc/init.d/crond restart
At
Este comando nos permite ejecutar tareas a una cierta hora solamente una vez.
* <hora><dia> Para especificar la fecha por completo.
El parmetro <hora> es obligatorio.

Podemos ingresar valores de la forma 1800,18:00,0600pm, o bien uno de los 3 valores especiales: noon (mediodia),
teatime (16:00) o midnight (00:00).
El parmetro <dia> es opcional.
Podemos especificarlo de las siguientes maneras: 12/23/2005 (notacin americana), 23.12.2005 (notacin europea).
Podemos omitir el ao, pero entonces slo podemos usar la notacin europea (por ejemplo: 23.12).
Tambin podemos especificar el mes abreviado como: Dec 23 o bien como 23 Dec.
Especificaciones
* now + <intervalo> Donde intervalo es: <n> (minutos|horas|das|semanas|mes).
Opciones
* -l Para mostrar la lista de tareas que tenemos programadas.
* -d <num_tarea> Para eliminar la tarea que queramos. Cada tarea tiene asociado un nmero que podemos ver
con la opcin anterior.
Ejemplo 1:
$ at 5:30pm
o bien
$ at 17:30
Una vez que hayamos ejecutado esto nos aparecer el prompt de at para que introduzcamos nuestros comandos o
tareas que queramos que se ejecuten a esa hora:
at> gmessage "Comienza la salva de datos!!"
Una vez hayamos terminado de introducir los comandos, presionaremos Control + D para salir de at.
Ejemplo 2:
Programar tareas para dentro de 3 horas:
$ at now + 3 hours
Copia de seguridad automatizada en Windows
A continuacin se presentan dos instrucciones para automatizar la copia de seguridad de

PostgreSQL Server en Windows Environment.
El primer mtodo utiliza pg_dump.exe junto con el archivo por lotes para llamarla. Este
archivo por lotes crear un nuevo archivo para cada da que se ejecute.
Las copias de seguridad del segundo mtodo utilizan PgPass, pg_dumpall.exe y un archivo por
lotes para hacer una copia de seguridad del servidor completo y escribir el archivo cada vez
que se ejecuta.
Uso de pgdump, nuevo archivo para cada da
Vaya a Servidor crear un directorio llamado Drive: \ PostgresqlBack y luego crear un
subdirectorio llamado "bin" en Drive: \ PostgresqlBack
En lugar de compilar pg_dump.exe, la instalacin de pgAdmin III tiene listo el pg_dump. Los
archivos siguientes son necesarios cuando se utiliza pg_dump.exe desde la instalacin de
pgAdmin III, estos archivos deben estar ubicados en la carpeta bin a lo largo de
pg_dump.exe
Comerr32.dll
Gssapi32.dll
K5sprt32.dll
Krb_32.dll
Libeay32.dll
Libiconv2.dll
Libpq.dll
Microsoft.VC80.CRT.manifest
Msvcm80.dll
Msvcp80.dll
Msvcr80.dll
Pg_dump.dll
Ssleay32.dll
Zlib1.dll
Crear archivo por lotes llamado algo, ejemplo es postgresqlBackup.bat. El archivo debe estar
ubicado en el directorio PostgresqlBack no en la carpeta bin.
Abra el Archivo y luego Copiar / Pegar lo siguiente
Apagado
Para / f "tokens = 1-4 delims = /" %% i in ("% date%") do (
Establecer dow = %% i
Set month = %% j
Set day = %% k
Set year = %% l
)
Set fechastr =% mes% _% da% _% ao%
Echo datestr es% datestr%
Set BACKUP_FILE = <NameOfTheFile> _% datestr% .backup

El nombre del archivo de respaldo de eco es% BACKUP_FILE%
SET PGPASSWORD = <PassWord>
Eco en
Bin \ pg_dump -i -h <HostName> -p 5432 -U <UserName> -F c -b -v -f% BACKUP_FILE%
<DATABASENAME>
Cambie <NameOfTheFile> por algo. Una idea es usar el nombre de la base de datos.
(Asegrese de que no haya espacios despus de la palabra BACKUP_FILE cualquier
espacio har que esta configuracin no funcione). Setting es la primera parte del nombre del
archivo seguida de la fecha en que se cre el archivo con la extensin .backup
Cambie la configuracin <PassWord> anterior a la contrasea correcta para los usuarios de
copia de seguridad. (Asegrese de que no haya espacios despus de la palabra
PGPASSWORD cualquier espacio har que este ajuste no funcione.) Descripcin de
pgPassword
Cambie <HostName> a direccin IP o nombre DNS del servidor que aloja Postgresql.
Cambiar <UserName> al usuario de copia de seguridad asegrese de que este usuario tiene
acceso a la base de datos con fines de copia de seguridad
Cambie <DATABASENAME> al nombre de la base de datos que se est realizando una copia
de seguridad.
Guarda el archivo
Crear tarea para el programador de tareas de MS
Una vez que haya elegido el contexto de seguridad para ejecutar la tarea, se recomienda
cambiar la seguridad del directorio donde se ejecuta la copia de seguridad y los archivos se
almacenan, ya que un nombre de usuario de alto nivel y una contrasea se almacenan en
texto sin formato.
Usando .pgpass y pgdumpall, mismo archivo
Para lograr una copia de seguridad automatizada en un entorno de Windows, hice lo siguiente.
Crear un archivo .pgpass
(Llam a mi pgpass.conf) y lo puso en algn lugar seguro. Lo tengo en un subdirectorio bajo el
script que ejecuta la copia de seguridad.
Bloquear el archivo .pgpass
Utilizando los permisos de NTFS, deshabilite el acceso a este archivo para todos excepto para
que el usuario pg se ejecute como
(Si ejecuta pg en la cuenta del sistema, debe configurarlo para que utilice sus propias
credenciales de usuario)
Crear un script para llamar a pg_dumpall
Mina se ve as:
SET PGPASSFILE = C: \ foo \ bar \ PG_BACKUP \ PGPASSFILE \ pgpass.conf
"C: \ Archivos de programa \ PostgreSQL \ 8.2 \ bin \ pg_dumpall.exe" -U scfcu_postgres> C: \
foo \ bar \ PG_BACKUP \ db.out current
Es importante tener en cuenta la primera lnea, que establece dinmicamente la variable de
entorno PGPASSFILE. Esto se libera una vez finalizado el script, de modo que slo este
proceso slo para el momento en que se ejecuta tiene inicio de sesin automtico. La
segunda lnea es un comando pg_dumpall muy bsico, con un nombre de usuario pasado (-
U) y el nombre de archivo de salida (db.out), as como la base de datos a la copia de
seguridad (en este caso 'actual')
Crear una tarea programada
He creado una tarea programada en Windows para ejecutar cada noche a las 11:00 PM. El
comando es
C: \ Windows \ System32 \ cmd.exe / c "C: \ foo \ bar \ PG_BACKUP \ pg_backup.bat"
Y comienza en el directorio
C: \ foo \ bar \ PG_BACKUP
Una vez que todo est configurado, pg_dumpall se ejecutar automticamente cada noche y
descargar un archivo en este directorio. En este punto, lo mejor es utilizar cualquier
solucin de copia de seguridad que est utilizando actualmente para realizar copias de
seguridad de todo el sistema (incluido ese directorio) y esperamos obtener una copia fuera
del sitio tambin. Si alguna vez necesita restaurar, puede utilizar el archivo db.out que ha
copiado. Mientras usted permanezca dentro del mismo nmero de versin durante dumpall y
restaure, todo debe ser magnfico.
Me tom un poco de tiempo para averiguar cmo pasar automticamente la contrasea de
forma segura (o tan seguro como se puede obtener en las ventanas). Esto no es a prueba de
balas, pero hemos estado corriendo esto desde hace algn tiempo en un db que contiene toda
la informacin de la mina de datos para una unin de crdito de 3 sucursales. Esperemos que
esto le ayudar a conseguir que va, y recortar que la interaccin del usuario molestos al
hacer copias de seguridad en Windows.
Rutinas de mantenimiento y monitoreo
Explain
Nota de Gilberto Castillo: El artculo lo encontr en Google y le hice algunas modificaciones.

EXPLAIN :Muestra Plan de consulta explcito del backend Postgres.
EXPLAIN [ VERBOSE ] consulta
VERBOSE :Bandera para mostrar el plan detallado de la consulta.
Entradas
Cualquier consulta.
Salidas
NOTICE: QUERY PLAN: plan
Descripcin
Este comando muestra el plan de ejecucin que el planificador Postgres genera para la consulta dada. El plan de
ejecucin muestra la manera en que sern escaneadas las tablas referenciadas; ya sea escaneo secuencial plano,
escaneo por ndice, etc. En el caso que se referencian varias tablas, los algoritmos de unin que sern utilizados para
agrupar las tuplas requeridas de cada tabla de entrada.
La opcin VERBOSE emite la representacin interna completa del rbol del plan, en vez de un resumen (y lo enva al
archivo log del postmaster tambin). Usualmente esta opcin es nicamente til para la correccin de errores (debug)
de Postgres.
Ejemplo 1. Para mostrar un plan de consulta para una consulta simple sobre una tabla con una nica columna de tipo
int4:
EXPLAIN SELECT * FROM foo;
NOTICE: QUERY PLAN:
Seq Scan on foo (cost=0.00..2.28 rows=128 width=4)
*.Costo inicio estimado (tiempo inicial que toma devolverse la primer tupla)
*.Costo total estimado (tiempo total para devolver todas las tuplas: por ejemplo, si se limita el nmero de tuplas
a devolver con una clusula
LIMIT, el planificador realiza una interpolacin apropiada entre los dos costos finales para estimar cul de
los planes es realmente el menos
costoso.)
*.Nmero estimado de filas escaniadas (Se cumple solamente si la ejecucin de la consulta es completa.)
*.Cantidad estimado de filas de salida.
El costo estimados es (disk pages read * seq_page_cost) + (rows scanned * cpu_tuple_cost). Por defecto,
seq_page_cost is 1.0 y cpu_tuple_cost is 0.01. Valor costo estimado es (2,24 * 1.0) + (4 * 0.01) = 2.28
seq_page_cost (floating point)
La suposicin del planificador sobre el costo medido en unidades de captura de pginas de disco. Por defecto es
1.0.
cpu_tuple_cost (floating point)

La suposicin del planificador sobre el costo de procesamiento de cada fila durante la consulta. Por defecto es 0.01.
Ejemplo 2. Para la misma tabla con un ndice para lograr una condicin equijoin en la consulta, EXPLAIN mostrar un
plan distinto:
EXPLAIN SELECT * FROM foo WHERE i = 4;
NOTICE: QUERY PLAN:
Index Scan using fi on foo (cost=0.00..0.42 rows=1 width=4)
Ejemplo 3. Para terminar, la misma tabla con un ndice para lograr una condicin equijoin en la consulta, EXPLAIN
mostrar lo siguiente para una consulta que utilice una funcin de agregacin:
EXPLAIN SELECT sum(i) FROM foo WHERE i = 4;
NOTICE: QUERY PLAN:
Aggregate (cost=0.42..0.42 rows=1 width=4)

-> Index Scan using fi on foo (cost=0.00..0.42 rows=1 width=4)
Resumen
Explain es la presentacin del costo estimado de ejecucin de la consulta, que es la suposicin del planificador sobre el
tiempo que tomar correr la consulta (medido en unidades de captura de pginas de disco). Muestran dos nmeros: el
tiempo inicial que toma devolverse la primer tupla, y el tiempo total para devolver todas las tuplas. Para la mayora de
las consultas lo que importa es el tiempo total, pero en algunos casos como una sub-consulta EXISTS el planificador
escoger el menor tiempo inicial en vez del menor tiempo total (ya que en todo caso el ejecutor se detendr despus de
obtener la primer tupla). Tambin, si se limita el nmero de tuplas a devolver con una clusula LIMIT, el planificador
realiza una interpolacin apropiada entre los dos costos finales para estimar cul de los planes es realmente el menos
costoso.
Uso de Vacuum
El vacuum es el proceso en el cual se eliminan definitivamente tuplas marcadas para borrar y hay
una reorganizacin de datos a nivel fsico.
Puede realizar vacuum utilizando el comando externo 'vacuumdb' y el cual puede recibir parmetros para realizar los
diferentes tipos de vaciamiento:
FREEZE
FULL
ANALYZE
S/Parametros de tipo
Este comando es muy til para automatizar vaciamientos a travs de cualquier sincronizador de tareas (ya sea el cron
de *nix u otro de Windows).
Asimismo, existe la opcin del Autovacuum, cuya funcionalidad es ir realizando de manera paulatina la mantencin de
nuestra base. Previamente y antes de activar esta funcionalidad, es recomendable leer sobre las consideraciones a
tener en cuenta, para no degradar la performance de nuestro servidor.
Usando Munin
Contents
[hide]
1 Qu
es
Munin?
2
Instalan
do
munin
3
Fichero
s de
configu
racin
4
Configu
rando el
servidor
5
Configu
rando
un nodo
6
Configu
rando el
usuario
de
acceso
para la
interfaz
web
7
Arranca
ndo
munin
8
Accedie
ndo a la
informa
cin
9
Plugins
para
Postgre
SQL
9.1
Instalac
in de
los
plugins
9.2
Descrip
cin de
Qu es Munin?
Munin es un programa de monitorizacin de servidores que genera estadsticas sobre su funcionamiento de los
recursos de nuestros servidores, como memoria, disco duro y servicios. Utiliza las herramientas RRDTool para generar
grficas de rendimiento de los parmetros del sistema analizados. Utiliza una interfaz web para mostrar las grficas
generadas, permite trabajar de forma distribuida, mostrando la informacin de varios servidores. Para ello se instala en
una SERVER la parte servidora de Munin y en el resto la parte cliente, que mandar los datos recopilados al servidor
para que ste los muestre. Est hecho en perl y permite el uso de plugins, lo cual lo hace realmente verstil.
Instalando munin
Munin est incluido en el depsito oficial de diferentes distribuciones:
root@lolo:~# apt-get install munin # si vamos a emplear el equipo como servidor
O
root@lolo:~# yum install munin
root@lolo:~# apt-get install munin-node # si vamos a leer datos de l

O
root@lolo:~# yum install munin-node
Munin puede usarse para monitorizar uno o varios equipos, por lo que munin-node debe instalarse en los equipos de los
cuales se recopilarn los datos y munin en el equipo que actuar a modo de servidor y que provee de servicio web.
Ficheros de configuracin
Munin cuenta con varios ficheros y directorios que hay que conocer.
/etc/munin/munin.conf Es el fichero de configuracin general y, ms concretamente, donde se configura el lado

servidor de munin. En este fichero se especifican los directorios a emplear y la configuracin de las diferentes
mquinas. Debe estar configurado en el servidor.
/etc/munin/munin-node.conf El fichero de configuracin del nodo. Munin ve a cada equipo que monitoriza como el
nodo de una red y mediante este fichero se especifica la configuracin. Debe existir en cada equipo.
/etc/munin/plugins/ Es el directorio donde munin lee los plugins a emplear. stos son simples enlaces al directorio real
de los plugins (/var/lib/munin/plugins/) y se pueden aadir y quitar de la manera ms simple, creando o borrando un
enlace.
/var/www/munin/ Directorio donde se vuelca por defecto el cdigo HTML generado con los informes. Se puede cambiar
en munin.conf. Debe pertenecer al usuario y grupos munin.
/var/lib/munin/ Directorio donde se guardan todos los datos de los diferentes nodos y con los que se generan las
grficas.
/var/log/munin/ Directorio de registros del sistema o logs. En las configuraciones de red es interesante el fichero munin-
nodes.log, que detalla la informacin enviada y transmitida desde el nodo.
/etc/cron.d/munin Fichero del cron que se ejecuta cada cinco minutos y que actualiza los datos del equipo en la base
de datos de munin.
/etc/cron.d/munin-node Fichero del cron que se ejecuta cada cinco minutos y que actualiza los datos de los nodos que
estn dados de alta.
/etc/init.d/munin-node Script para reiniciar la solicitud de informacin a los nodos.
Configurando el servidor
Editamos el fichero /etc/munin/munin.conf:
# Example configuration file for Munin, generated by 'make build'
dbdir /var/lib/munin ## directorio para guardar los datos y ficheros a
emplear
htmldir /var/www/munin ## los informes generados
logdir /var/log/munin ## los logs
rundir /var/run/munin ## los semforos
tmpldir /etc/munin/templates ## las plantillas html
#graph_period minute
#
[server1.etecsa.cu]
address la.ip.de.server1
local_address la.ip.de.server1
use_node_name yes
#
[localhost.etecsa.cu]
address 127.0.0.1
local_address 127.0.0.1
use_node_name yes
**si no especifico la direccin local (local_address) que tiene el equipo,
munin no genera las grficas, con lo que se incluye la direccin IP
por partida doble.
Configurando un nodo
Editamos el fichero /etc/munin/munin-node.conf:
#
# Example config-file for munin-node
#
log_level 4
log_file /var/log/munin/munin-node.log
port 4949
pid_file /var/run/munin/munin-node.pid
background 1
setseid 1
host *
user root
group root
setsid yes
ignore_file ~$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
host_name localhost.etecsa.cu ## nombre con que el servidor identifica a

esta mquina
allow ^127\.0\.0\.1$ ## direccin IP dejaremos que se
conecten...pondremos la direccin IP del
servidor munin
Configurando el usuario de acceso para la interfaz web

htpasswd -cm /etc/munin/munin-htpasswd muninadmin
Arrancando munin
Munin se ejecuta cada cinco minutos como un trabajo del cron. Los scripts estn en /etc/cron.d/ y se pueden modificar
para que ejecute lecturas cada minuto y as realizar pruebas.
Iniciar el cliente en todas las mquinas:
root@lolo:~# /etc/init.d/munin-node start
Accediendo a la informacin
Introducimos en el navegador la direccin de htmldir, en este caso file:///var/www/munin/
http://localhost/munin (si contamos con un servidor web).
Plugins para PostgreSQL

El uso de plugins mejora la versatilidad de munin. A partir de la version 1.4 Munin incluye los plugins necesarios para
monitorear PostgreSQL.
Instalacin de los plugins
A continuacion vamos a describir como instalarlo y configurarlo.
Todo los plugins estn programados en perl y necesitan el modulo DBD::Pg Perl.
Para Debian
root@lolo:~# apt-get install libdbd-pg-perl
Para Centos
root@lolo:~# yum install perl-DBD-Pg
Necesitamos activar los parmetros de recoleccin de estadistica y monitoreo en Postgresql.

Para ello editamos el postgresql.conf:
logging_collector = on
- Query/Index Statistics Collector -

track_activities = on
track_counts = on
update_process_title = on
- Statistics Monitoring -
log_parser_stats = on
log_planner_stats = on
log_executor_stats = on
log_statement_stats = off
Instalar plugins de Munin es muy sencillo. Lo nico que tienes que hacer es copiarlos a /usr/share/munin/plugins/
Para Centos
Descompactando el archivo: muninpgplugins-0.2.2.tar.gz
root@lolo:~# tar xvzf muninpgplugins-*.tar.gz
root@lolo:~# cd plugins
Para Debian
root@lolo:~# apt-get install munin-plugins-extra
Descripcin de los plugins

pg__connections Este plugin muestra el numero de conexiones en idle, espera y conectadas.
pg__db_size Este plugin muestra el tamao de base de datos suministrado por pg_database_size('my_db');
pg__locks Este plugin muestra todos los posibles bloqueos desde postgresql.
pg__stat_database Este plugin muestra todos datos desde una base de datos para una vista especifica.
pg__stat_tables Este plugin muestra todos las columnas en pg_stat_*_tables (excepto *vacuum y *analyze). Este
informacin es utilizada para agregar grficos en el munin.conf (like ratio). Con el parametro especial (statscope)
especificamos si utilizamos pg_stat_all_tables, pg_stat_user_tables o pg_stat_sys_tables (user es valos por defecto).
pg__statio_tables Este plugin muestra todos las columnas en pg_statio_*_tables. ste informacin es utilizada para
agregar grficos en el munin.conf (like ratio). Con el parametro especial (statscope) especificamos si utilizamos
pg_stat_all_tables, pg_stat_user_tables o pg_stat_sys_tables (user es valos por defecto).
pg__stat_bgwriter Este plugin muestra todos las columnas en pg_stat_bgwriter. Este informacin es utilizada para
agregar grficos en el munin.conf (like ratio). Como todas las bases de datos tienen algn valor en esta tabla, no es
necesario especificar la base de datos.
Para activar los plugins
Tener en cuenta que si el nombre del plugin es por ej. postgres_ significa que cuando crees los enlaces simblicos en
/etc/munin.d/plugins segn lo que pongas despus va a monitorizar una cosa u otra. Lo mejor es ver el cdigo del plugin
en cuestin para ver que parmetros soporta:
Creamos los enlaces simblicos en /etc/munin/plugins.
ln -s '/usr/share/munin/plugins/postgres_autovacuum' '/etc/munin/plugins/postgres_autovacuum'
ln -s '/usr/share/munin/plugins/postgres_bgwriter' '/etc/munin/plugins/postgres_bgwriter'
ln -s '/usr/share/munin/plugins/postgres_cache_' '/etc/munin/plugins/postgres_cache_ALL'
ln -s '/usr/share/munin/plugins/postgres_checkpoints' '/etc/munin/plugins/postgres_checkpoints'
ln -s '/usr/share/munin/plugins/postgres_connections_' '/etc/munin/plugins/postgres_connections_ALL'
ln -s '/usr/share/munin/plugins/postgres_connections_db' '/etc/munin/plugins/postgres_connections_db'
ln -s '/usr/share/munin/plugins/postgres_locks_' '/etc/munin/plugins/postgres_locks_ALL'
ln -s '/usr/share/munin/plugins/postgres_querylength_' '/etc/munin/plugins/postgres_querylength_ALL'
ln -s '/usr/share/munin/plugins/postgres_size_' '/etc/munin/plugins/postgres_size_ALL'
ln -s '/usr/share/munin/plugins/postgres_transactions_' '/etc/munin/plugins/postgres_transactions_ALL'
ln -s '/usr/share/munin/plugins/postgres_users' '/etc/munin/plugins/postgres_users'
ln -s '/usr/share/munin/plugins/postgres_xlog' '/etc/munin/plugins/postgres_xlog'
Ejemplos de posibles configuraciones

Para adicionar el llamado a los plugins editamos el fichero /etc/munin/plugin-conf.d/munin-node:
Las varibles a configurar son:
env.PGHOST = cual servidor de base de datos usar. Defaults para 'localhost'.
env.PGDATABASE = cual base de datos usar. Defaults para template1.
env.PGUSER = cual cuanta de usuario de Postgresql usar. Defaults para 'postgres'. Puede ser el mismo usuario,que
ejecuta los plugins de Munin.
env.PGPASSWORD = cual es la clave del usario correspondiente. Default para . Guada relacin con el tipo de acceso
en el pg_hba.conf.
ejemplo1
[pg_*]
user postgres
ejemplo2--Uso base de datos foobase.

[pg_foobase*]
user foouser
env.PGDATABASE foobase
ejemplo3--Uso servidor local, ident autentificacin con usuario 'postgres'.

[postgres_*]
user postgres
ejemplo4--Uso servidor, TCP autentificacin con usuario y contrasea.

[postgres_*]
env.PGHOST localhost
env.PGUSER someuser
env.PGPASSWORD somepassword
Para probar el funcionamiento de los plugins

Reiniciamos munin
root@lolo:~# /etc/init.d/munin-node restart
y esperamos a que empiece a recopilar informacin para leer los logs a ver si todo funciona en condiciones, O bien de
forma directa,
root@lolo:~# /usr/share/munin/plugins/postgres_activate_lock
Usando Nagios
Contents
[hide]
1 Por
qu
usar
Nagios?
2
Configu
rar el
servidor
de
monitor
eo
2.1
Requisit
os
2.2
Instalac
in
(como
usuario
root)
2.2.1
Crear
un
usuario
nagios
2.2.2
Instalar
nagios
2.3
Configu
racin
2.3.1
Editar
el
archivo
/usr/loc
al/nagio
s/etc/ob
jects/co
ntacts.c
fg
2.3.2
Configu
rar la
interfas
e web
2.4
Instalar
los
plugins
de
Por qu usar Nagios?
Nagios es un sistema open source de monitoreo de redes ampliamente utilizado, que vigila los equipos (hardware) y
servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no sea el deseado.
Configurar el servidor de monitoreo

Requisitos
Servidor Web (Este manual asume que se usar Apache)
Php (Para la interface web)
Gcc
Libgd (es una librera grfica necesaria para mostrar el statusmap)
Perl
Servidor de correo (Opcional. Para enviar las alertas por correo)
Instalacin (como usuario root)
Crear un usuario nagios
useradd -m nagios
passwd nagios
Instalar nagios
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.0.6.tar.gz
gunzip -dc nagios-3.0.6.tar.gz | tar xvf -
cd nagios-3.0.6
./configure --with-command-group=nagios
make all
make install
make install-init
make install-config
make install-commandmode
Configuracin
Editar el archivo /usr/local/nagios/etc/objects/contacts.cfg
Este cambio es para indicar a que correo se notificarn las alertas configuradas.
reemplazar nagios@localhost por el correo del administrador
Configurar la interfase web

make install-webconf
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
chown nagios.nagios /usr/local/nagios/etc/htpasswd.users
chmod 664 /usr/local/nagios/etc/htpasswd.users
service httpd restart
Instalar los plugins de Nagios

El plugin para PostgreSQL lo instalaremos luego manualmente, estos es por dos motivos:
1. Para instalar la ltima versin y
2. Para no tener problemas de dependencias en caso de que en el servidor de monitoreo no tengamos instalado
PostgreSQL
cd ..
wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.13.tar.gz
gunzip -dc nagios-plugins-1.4.13.tar.gz | tar xvf -
cd nagios-plugins-1.4.13
./configure --with-nagios-user=nagios --with-nagios-group=nagios --without-pgsql
make
make install
Iniciar Nagios
cd /etc/init.d
chkconfig --add nagios
chkconfig nagios on
Para comprobar que todo esta bien

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Finalmente
service nagios start
En este momento ya es posible ingresar a Nagios, abriendo el navegador de internet y poniendo como direccin:
http://localhost/nagios
Ingrese como usuario nagiosadmin y como clave la que indico cuando configuraba la interfase web.
Si instalo en la misma mquina que va a ser monitoreada pasar a la instalacin del plugin para PostgreSQL, de lo
contrario contine con la siguiente seccin.
Configurar la mquina que sera monitoreada

Requisitos
PostgreSQL (Las instrucciones en este manual se probaron usando la versin 8.3.7)
Xinetd
Gcc
Perl
Crear un usuario Nagios
useradd -m nagios
passwd nagios
Instalar los plugins de Nagios

El plugin para PostgreSQL lo instalaremos luego manualmente para asegurarnos de usar la ltima versin.
wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.13.tar.gz
gunzip -dc nagios-plugins-1.4.13.tar.gz | tar xvf -
cd nagios-plugins-1.4.13
./configure --with-nagios-user=nagios --with-nagios-group=nagios --without-pgsql
make
make install
chown -R nagios.nagios /usr/local/nagios
Instalar el modulo nrpe de Nagios

wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
gunzip -dc nrpe-2.12.tar.gz | tar xvf -
cd nrpe-2.12
./configure
make all
make install-plugin
make install-daemon
make install-daemon-config
make install-xinetd
Configurar el modulo nrpe

Modificar el archivo /etc/xinet.d/nrpe
modificar el valor del campo only_from por la ip del servidor que se va a monitorear
Modificar el archivo /etc/services

agregar la siguiente linea nrpe 5666/tcp #NRPE
Configurar el servidor de monitoreo para que chequee los servicios en la

mquina remota
Instalar el modulo nrpe de Nagios
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
gunzip -dc nrpe-2.12.tar.gz | tar xvf -
cd nrpe-2.12
./configure
make all
make install-plugin
Probar el modulo nrpe
/usr/local/nagios/libexec/check_nrpe -H <ip servidor monitoreado>
Editar el archivo /usr/local/nagios/etc/objects/commands.cfg

Agregar las siguientes lineas al final del archivo
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}
Debemos indicarle a Nagios que vamos a monitorear otra maquina editando el archivo /usr/local/nagios/etc/nagios.cfg
Agregar la siguiente linea en la seccion OBJECT CONFIGURATION FILE(S):
cfg_file = /usr/local/nagios/etc/objects/dbhost.cfg
Crear la definicion del host en un archivo dbhost.cfg

define host{
use linux-server
host_name dbserver
alias pgsql 8.3
address IP.del.servidor.PostgreSQL
}
service nagios restart
Instalar plugin para monitorear PostgreSQL (en el servidor que se va a monitorear)

Descargar el archivo check_postgres.tar.gz desde http://bucardo.org/check_postgres
gunzip -dc check_postgres.tar.gz | tar xvf -
cd check_postgres
cp check_postgres.pl /usr/local/nagios/libexec/.
perl /usr/local/nagios/libexec/check_postgres.pl symlinks
Para instalar chequeos se debe crear una entrada por cada servicio que vayamos a monitorear en el archivo
/usr/local/nagios/etc/nrpe.cfg similar a (deben agregados en la seccion COMMAND DEFINITIONS):
command[check_postgres_locks]=/usr/local/nagios/libexec/check_postgres_locks -w 2 -c 3
Donde los comandos pueden tomarse de http://bucardo.org/check_postgres/check_postgres.pl.html

Luego debemos indicar los servicios a monitorear, creando entradas como las siguientes en el archivo
/usr/local/nagios/etc/objects/dbhost.cfg en el servidor de monitoreo:
define service {
use generic-service
host_name dbserver
service_description PGSQL locks
check_command check_nrpe!check_postgres_locks
}
define service{
use generic-service
host_name dbserver
service_description CPU Load
check_command check_nrpe!check_load
}
define service{
use generic-service
host_name dbserver
service_description Current users
check_command check_nrpe!check_users
}
define service{
use generic-service
host_name dbserver
service_description Total Processes
check_command check_nrpe!check_total_procs
}
define service{
use generic-service
host_name dbserver
service_description Zombie Processes
check_command check_nrpe!check_zombie_procs
}
Monitoreo de bloqueos
Mirando el link pg_locks nos muestra que bloqueos han sido otorgados y que procesos estn
esperando por estos. Una buena consulta para empezar a mirar los problemas inherentes a los
bloqueos:
SELECT relname,pg_locks.*
FROM pg_class,pg_locks
WHERE relfilenode=relation AND NOT GRANTED;
Revisando cuales son los procesos que estan manteniendo o esperando los bloqueos, es fcil si utiliza la referencia en
pg_stat_activity
Archivado Continuo y Recuperacin de Punto en Tiempo (PITR)

En todo momento, PostgreSQL mantiene un registro de escritura previa (WAL) en el
subdirectorio pg_xlog / del directorio de datos del clster. El registro registra cada cambio
realizado en los archivos de datos de la base de datos. Este registro existe principalmente
para propsitos de seguridad contra accidentes: si el sistema falla, la base de datos se puede
restaurar a la consistencia "repitiendo" las entradas de registro realizadas desde el ltimo
punto de control. Sin embargo, la existencia del registro permite utilizar una tercera
estrategia para realizar copias de seguridad de bases de datos: podemos combinar una copia
de seguridad a nivel de sistema de archivos con una copia de seguridad de los archivos
WAL. Si la recuperacin es necesaria, restauramos la copia de seguridad del sistema de
archivos y luego reproducir desde los archivos WAL con copia de seguridad para llevar el
sistema a un estado actual. Este enfoque es ms complejo de administrar que cualquiera de
los enfoques anteriores, pero tiene algunos beneficios significativos:
No necesitamos una copia de seguridad del sistema de archivos perfectamente coherente como
punto de partida. Cualquier incoherencia interna en la copia de seguridad ser corregida por
la repeticin de registro (esto no es significativamente diferente de lo que sucede durante la
recuperacin del accidente). Por lo tanto, no necesitamos una capacidad de instantnea del
sistema de archivos, simplemente tar o una herramienta similar de archivado.
Puesto que podemos combinar una secuencia indefinidamente larga de archivos WAL para la
reproduccin, la copia de seguridad continua se puede lograr simplemente continuando con
el archivo de los archivos WAL. Esto es particularmente valioso para las bases de datos
grandes, donde puede no ser conveniente tomar una copia de seguridad completa con
frecuencia.
No es necesario volver a reproducir las entradas WAL hasta el final. Podramos detener la
repeticin en cualquier momento y tener una instantnea consistente de la base de datos
como era en ese momento. Por lo tanto, esta tcnica admite la recuperacin de punto a
tiempo: es posible restaurar la base de datos a su estado en cualquier momento desde que se
realiz la copia de seguridad de base.
Si alimentamos continuamente la serie de archivos WAL a otra mquina que se ha cargado con
el mismo archivo de respaldo de base, tenemos un sistema de espera en caliente: en
cualquier momento podemos abrir la segunda mquina y tendr una copia casi actual de la
base de datos.
Nota: pg_dump y pg_dumpall no producen copias de seguridad a nivel de sistema de archivos

y no pueden utilizarse como parte de una solucin de archivado continuo. Estos volcados
son lgicos y no contienen suficiente informacin para ser utilizados por WAL replay.
Al igual que con la tcnica de copia de seguridad simple del sistema de archivos, este mtodo
slo puede admitir la restauracin de un clster de base de datos completo, no de un
subconjunto. Adems, requiere mucho almacenamiento de archivos: la copia de seguridad
base puede ser voluminosa y un sistema ocupado generar muchos megabytes de trfico
WAL que deben archivarse. An as, es la tcnica de copia de seguridad preferida en muchas
situaciones en las que se necesita una alta fiabilidad.
Para recuperar correctamente utilizando el archivado continuo (tambin llamado "copia de

seguridad en lnea" por muchos proveedores de bases de datos), necesita una secuencia
continua de archivos WAL archivados que se extiende al menos hasta la hora de inicio de la
copia de seguridad. As que para empezar, debe configurar y probar su procedimiento para el
archivo de archivos WAL antes de tomar su primera base de copia de seguridad. En
consecuencia, primero debatiremos la mecnica del archivo de archivos WAL.
24.3.1. Configuracin del archivo WAL
En un sentido abstracto, un sistema PostgreSQL en ejecucin produce una secuencia

indefinidamente larga de registros WAL. El sistema divide fsicamente esta secuencia en
archivos de segmento WAL, que son normalmente 16MB cada uno (aunque el tamao del
segmento puede ser alterado al construir PostgreSQL). Los archivos de segmento reciben
nombres numricos que reflejan su posicin en la secuencia WAL abstracta. Cuando no se
utiliza el archivado WAL, el sistema normalmente crea slo unos pocos archivos de
segmento y luego los "recicla" al cambiar el nombre de los archivos de segmento que ya no
son necesarios a nmeros de segmento ms altos. Se supone que los archivos de segmentos
cuyo contenido precede al punto de control anterior a la ltima ya no son de inters y pueden
reciclarse.
Al archivar datos WAL, necesitamos capturar el contenido de cada archivo de segmento una
vez que se llena, y guardar esos datos en algn lugar antes de que el archivo de segmento se
recicle para su reutilizacin. Dependiendo de la aplicacin y del hardware disponible, podra
haber muchas formas diferentes de "guardar los datos en algn lugar": podramos copiar los
archivos de segmento a un directorio montado en NFS en otra mquina, escribirlos en una
unidad de cinta Una forma de identificar el nombre original de cada archivo), o agruparlos y
grabarlos en CD, o cualquier otra cosa. Para proporcionar flexibilidad al administrador de
bases de datos, PostgreSQL intenta no hacer ninguna suposicin sobre cmo se realizar el
archivado. En lugar de ello, PostgreSQL permite al administrador especificar un comando de
shell que se ejecutar para copiar un archivo de segmento completado a donde sea necesario.
El comando podra ser tan simple como un cp, o podra invocar un script de shell complejo -
todo depende de usted.
Replicacin y alta disponibilidad de PostgreSQL con

pgpool-II
Vie, 17/07/2009 - 19:50 rafaelma
En este artculo se muestra cmo instalar, configurar y mantener un clster de servidores

de bases de datos PostgreSQL gestionados mediante un middleware llamado pgpool-II
sobre el sistema operativo Debian GNU/Linux.
Dicho clster ofrece capacidades de replicacin, balanceo de carga y un pool de

conexiones, y es capaz de realizar failover o degeneracin de un nodo que deje de
funcionar y de recuperar nodos cados en lnea (sin dejar de dar servicio). Se trata de un clster activo-
pasivo, si bien se hace uso del nodo pasivo para lectura con el propsito de mejorar la productividad del
sistema.
ndice
1. Introduccin
1. Failover cluster
2. Sobre PostgreSQL
3. Sobre pgpool-II
4. Sobre Debian GNU/Linux
2. Arquitectura del sistema
3. Instalacin de paquetes y configuracin de dependencias
4. Configuracin de PostgreSQL
5. Configuracin de pgpool-II
6. Pruebas de replicacin
7. Recuperacin en lnea
8. El Write-Ahead Log
1. Procedimiento completo
2. Primera fase
3. Segunda fase
4. Tercera fase
5. Pasos finales
6. Scripts necesarios
1. wal_archiving
2. pgpool-failover
3. pgpool-failback
4. base-backup
5. pgpool-recovery-pitr
6. pgpool_remote_start
9. Comandos de PCP
10.Simulacin de cada y recuperacin de un nodo
11.Alta disponibilidad de pgpool-II
1. El proyecto Linux High Availability
2. Instalacin de Heartbeat
3. Configuracin de Heartbeat
4. Simulacin de la cada del servicio
12.Herramientas de monitorizacin
1. pg_osmem y pg_buffercache
2. pg_top
3. ps
4. pgd
5. iotop
13.Optimizacin de PostgreSQL
1. Autovacuum y cargas de datos
2. Procesos errantes
14.FAQ (Frequently Asked Question)
15.Bibliografa
Introduccin
Failover cluster
Un failover cluster (o clster activo-pasivo) es un grupo de ordenadores independientes que trabajan

conjuntamente para incrementar la disponibilidad de diversas aplicaciones y servicios. Los servidores en
el clster (llamados nodos) estn interconectados mediante cables fsicos y por software. Si uno de los
nodos cae, otro empieza a dar servicio (proceso conocido como failover) sin necesidad de intervencin
humana. Esta gua describe los pasos para instalar y configurar un failover clster con dos o ms nodos.
Sobre PostgreSQL
PostgreSQL es la base de datos relacional de cdigo abierto ms avanzada del mundo. Distribuida bajo
licencia BSD (del ingls, Berkeley Software Distribution), lleva ms de 15 aos desarrollndose y su
arquitectura goza de una excelente reputacin por su fiabilidad, integridad de datos y correctitud.
PostgreSQL dispone de versiones para prcticamente todos los sistemas operativos y cumple totalmente
con ACID (del ingls, Atomicity, Consistency, Isolation, Durability). Tiene soporte para claves extranjeras,
joins, vistas, disparadores y procedimientos almacenados (en mltiples lenguajes de programacin).
Incluye la mayora de los tipos de datos de SQL92 y SQL99 y, asimismo, soporta el almacenamiento de
grandes objetos binarios, como imgenes, sonidos y vdeos. Tiene interfaces de programacin nativas
para C/C++, Java, .Net, Perl, PHP, Python, Ruby, Tcl y ODBC, entre otros, y una excepcional
documentacin.
PostgreSQL ofrece sofisticadas caractersticas tales como control concurrente multiversin (MVCC), point
in time recovery (PITR), tablespaces, replicacin asncrona, transacciones anidadas (savepoints), copias
de seguridad en caliente/en lnea, un sofisticado planificador/optimizador de consultas y write ahead
logging para ser tolerante a fallos de hardware. Soporta juegos de caracteres internacionales,
codificaciones de caracteres multibyte, Unicode y realiza ordenaciones dependiendo de la configuracin
de idioma local, de la diferenciacin de maysculas y minsculas y del formato. Es altamente escalable
tanto en la cantidad bruta de datos que puede manejar como en el nmero de usuarios concurrentes que
puede atender. Hay sistemas activos en produccin con PostgreSQL que manejan ms de 4 terabytes de
datos.
Sobre pgpool-II
pgpool-II habla los protocolos de frontend y backend de PostgreSQL, y pasa las conexiones entre ellos.
De ese modo, una aplicacin de base de datos (frontend) cree que pgpool-II es el verdadero servidor de
PostgreSQL, y el servidor (backend) ve a pgpool-II como uno de sus clientes. Debido a que pgpool-II es
transparente tanto para el servidor como para el cliente, una aplicacin de base de datos existente puede
empezar a usarse con pgpool-II casi sin ningn cambio en su cdigo fuente.
pgpool-II funciona sobre Linux, Solaris, FreeBSD y la mayora de las arquitecturas UNIX. Windows no
est soportado. Las versiones de PostgreSQL soportadas son de la 6.4 para arriba. Para usar la
paralelizacin de consultas es necesaria la versin 7.4 o superior.
pgpool-II proporciona las siguientes caractersticas:
Limita el excedente de conexiones. PostgreSQL soporta un cierto nmero de conexiones

concurrentes y rechaza las que superen dicha cifra. Aumentar el lmite mximo de conexiones
incrementa el consumo de recursos y afecta al rendimiento del sistema. pgpool-II tiene tambin
un lmite mximo de conexiones, pero las conexiones extras se mantienen en una cola en lugar
de devolver un error inmediatamente.
Pool de conexiones. pgpool-II mantiene abiertas las conexiones a los servidores PostgreSQL y las
reutiliza siempre que se solicita una nueva conexin con las mismas propiedades (nombre de
usuario, base de datos y versin del protocolo). Ello reduce la sobrecarga en las conexiones y
mejora la productividad global del sistema.
Replicacin. pgpool-II puede gestionar mltiples servidores PostgreSQL. El uso de la funcin de
replicacin permite crear una copia en dos o ms discos fsicos, de modo que el servicio puede
continuar sin parar los servidores en caso de fallo en algn disco.
Balanceo de carga. Si se replica una base de datos, la ejecucin de una consulta SELECT en
cualquiera de los servidores devolver el mismo resultado. pgpool-II se aprovecha de la
caracterstica de replicacin para reducir la carga en cada uno de los servidores PostgreSQL
distribuyendo las consultas SELECT entre los mltiples servidores, mejorando as la productividad
global del sistema. En el mejor caso, el rendimiento mejora proporcionalmente al nmero de
servidores PostgreSQL. El balanceo de carga funciona mejor en la situacin en la cul hay muchos
usuarios ejecutando muchas consultas al mismo tiempo.
Paralelizacin de consultas. Al usar la funcin de paralelizacin de consultas, los datos pueden
dividirse entre varios servidores, de modo que la consulta puede ejecutarse en todos los
servidores de manera concurrente para reducir el tiempo total de ejecucin. La paralelizacin de
consultas es una solucin adecuada para bsquedas de datos a gran escala.
Sobre Debian GNU/Linux
Debian GNU/Linux es un sistema operativo libre (el conjunto de programas bsicos y utilidades que hacen
que un ordenador funcione). Debian utiliza el ncleo Linux y las herramientas bsicas de GNU. Para esta
instalacin se utilizar el sistema operativo Debian Lenny para la arquitectura x86_64 (AMD64/EM64T),
partiendo de una instalacin bsica, sin ninguna tarea seleccionada en el selector de tareas del instalador.
El sistema de ficheros elegido ser XFS. La misma instalacin puede obtenerse con Debian Etch y el
repositorio de backports.
Arquitectura del sistema

El trmino clster hace referencia a un conjunto de sistemas informticos trabajando conjuntamente por
un objetivo comn. Como puede apreciarse, esta definicin es muy genrica. No es, sino, un reflejo de la
gran variedad y diversidad de acercamientos posibles a la hora de configurar un clster y, por lo tanto,
prueba de que el lector no debe tomar la arquitectura utilizada en el artculo ms que como referencia y
base para sus futuros trabajos.
En el clster de este artculo se persiguen dos objetivos: uno, la alta disponibilidad, y dos, el rendimiento.
La funcionalidad que persigue el clster es nicamente la de servidor de base de datos, pero lo hace a
travs de tres aplicaciones:
PostgreSQL, el sistema gestor de bases de datos (S.G.B.D.)

pgpool-II, el middleware que gestiona la alta disponibilidad de los servidores de PostgreSQL.
Heartbeat, un software que usaremos para dar alta disponibilidad a pgpool-II y a la direccin IP
de servicio.
Esta configuracin nos permite obtener alta disponibilidad de todos los servicios y recursos en las dos
mquinas destinadas a este clster. El diagrama de la arquitectura resultante sera el siguiente:
Instalacin de paquetes y configuracin de dependencias

Se toma como punto de inicio un sistema x86_64 con Debian GNU/Linux Etch o Lenny instalado. Se
utilizarn las siguientes versiones de software:
PostgreSQL 8.3.x
pgpool-II 2.2.x
Heartbeat 2.x
Antes de empezar, instalaremos un conjunto de paquetes bsico para cualquier sistema, as como una
serie de utilidades que nos harn falta para la gestin y el mantenimiento del clster:
apt-get install ntp openssl file psmisc sysstat bzip2 unzip nmap dstat rsync wget ccze tcpdump pciutils dnsutils host
rsync lo usaremos para la recuperacin en lnea de nodos, ntp para mantener el reloj del sistema
sincronizado. El prototipo inicial de este clster se prob en una mquina con dos instancias de Xen y una
base de datos de prueba creada con pgbench. Ms tarde se configur una versin de preproduccin sobre
sendos Intel Quad Core con 8 GB de RAM y la versin final del clster se configur sobre dos nodos con
doble Intel Quad Core cada uno y 16 GB de RAM. La base de datos final ocupa algo ms de 30 GB y se
encuentra sobre dos discos SAS de 15.000 RPM en RAID 1.
A efectos de este artculo, a continuacin se presenta un resumen de los datos de configuracin que se
usarn:
Nodo 1
Hostname: pgsql1.dominio.com
Direccin IP de administracin: 192.168.0.3
Nodo 2
Hostname: pgsql2.dominio.com
Direccin IP de administracin: 192.168.0.4
Mscara de red de 24 bits.
Direccin IP del router: 192.168.0.1
pgpool-II
Direccin IP de servicio: 192.168.0.2
Puerto de gestin: 9898
Puerto de servicio: 9999
Los conceptos utilizados en esta descripcin se irn explicando a lo largo del artculo. Es preciso que las
entradas correspondientes a los datos anteriores existan en el fichero /etc/hosts:
127.0.0.1 localhost.localdomain localhost
192.168.0.1 router.dominio.com router
192.168.0.2 pgpool2.dominio.com pgpool2
192.168.0.3 pgsql1.dominio.com pgsql1
Empezaremos configurando PostgreSQL en ambos nodos pero pgpool-II slo en el nodo pgsql1. Los
comandos debern ejecutarse como root o mediante sudo, a menos que se indique lo contrario
(normalmente comandos que se ejecutarn con el usuario postgres).
Las dependencias de compilacin de pgpool-II (las cabeceras de la librera de PostgreSQL, el paquete de

desarrollo de PostgreSQL para pogramacin de servidores y las utilidades de compilacin de GNU) las
resolveremos mediante la instalacin de los siguientes paquetes:
apt-get install libpq-dev postgresql-server-dev-8.3 bison build-essential
Una vez resueltas las dependencias, empezaremos instalando PostgreSQL en ambos nodos:
apt-get install postgresql-8.3 postgresql-contrib-8.3 postgresql-doc-8.3 uuid libdbd-pg-perl
La instalacin por defecto de PostgreSQL en Debian ya nos deja un sistema gestor de base de datos
funcionando. Finalmente, descargamos pgpool-II, lo descomprimimos e instalamos en /opt/pgpool2:
cd /usr/local/src
wget http://pgfoundry.org/frs/download.php/2191/pgpool-II-2.2.2.tar.gz
tar --extract --gzip --file pgpool-II-2.2.2.tar.gz
cd pgpool-II-2.2.2
./configure --prefix=/opt/pgpool2
make
make install
cd /usr/local/src/pgpool-II-2.2.2/sql/pgpool-recovery
make
make install
su - postgres -c "psql -f /usr/local/src/pgpool-II-2.2.2/sql/pgpool-recovery/pgpool-recovery.sql template1"
A partir de aqu, todas las bases de datos que creemos heredarn las funciones existentes en template1.
Configuracin de PostgreSQL
Tal y como se ha dicho anteriormente, los siguientes pasos aplican a ambas instancias de PostgreSQL en
los nodos pgsql1 y pgsql2.
Empezaremos editando la configuracin de PostgreSQL para permitir el acceso incondicional del usuario
pgpool2, que ser nuestro usuario de base de datos del clster. Por incondicional nos referimos al uso del
modo trust, que permite la validacin del usuario sin necesidad de contrasea. Esto es un requerimiento
de pgpool-II para el tipo de configuracin del clster que tendremos al final del artculo, por lo cul
deberemos prestar especial atencin a los filtros de acceso por IP que configuremos tanto en los
servidores PostgreSQL como en el cortafuegos de los nodos.
Comenzaremos, como usuario postgres, aadiendo el usuario de base de datos (role) pgpool2, sin
contrasea:
su - postgres
createuser --superuser pgpool2
Para facilitar el trabajo en este artculo lo hemos dado de alta como superusuario. En realidad, si creamos
la base de datos en todos los nodos como superadministrador postgres y le otorgamos propiedad al
usuario pgpool2, ste puede ser un usuario con el role ms bsico (no superusuario, sin capacidad de
crear bases de datos).
Editamos ahora el fichero /etc/postgresql/8.3/main/pg_hba.conf y aadimos el acceso para el usuario

pgpool2 desde la direccin IP donde se ejecutar pgpool-II (en estos momentos 192.168.0.3):
# TYPE DATABASE USER CIDR-ADDRESS METHOD
local all all ident sameuser
host all pgpool2 192.168.0.3/32 trust
host all all ::1/128 md5
Al igual que durante la creacin del usuario pgpool2, para facilitar este artculo se permite el acceso a
todas las bases de datos a dicho usuario. En un entorno de produccin sera preciso restringir dicho
acceso a la base de datos que se vaya a usar.
Asimismo, si se quiere acceder directamente a la base de datos sin pasar por pgpool-II, por ejemplo para
realizar pruebas de rendimiento o para su monitorizacin, debern aadirse las direcciones IP de los
clientes desde los que se conecten dichas aplicaciones. En este caso, si se desea, y siempre y cuando las
direcciones IP de origen sean diferentes, puede cambiarse el mtodo de autenticacin a MD5 y crearse el
usuario pgpool2 con contrasea.
A continuacin activamos el archivado del Write-Ahead Log (WAL) de PostgreSQL, pues nos har falta
para poder usar PITR (Point-In-Time Recovery) desde pgpool-II. Editamos el fichero de configuracin
/etc/postgresql/8.3/main/postgresql.conf y cambiamos los dos siguientes parmetros:
archive_mode = on
archive_command = 'exit 0'
Ya que slo haremos uso de la caracterstica de PITR cuando vayamos a recuperar un nodo cado o aadir
uno nuevo, por defecto hemos configurado el parmetro archive_command para que no haga nada (exit
0). Esto lo hacemos debido a que la activacin o desactivacin del archivado de ficheros WAL requiere de
un reinicio del servidor, pero la alteracin del comando o script que realiza la tarea de archivar el fichero
WAL rotado por PostgreSQL tan slo requiere de una recarga de la configuracin.
As, PostgreSQL se comportar como si no estuviera archivando ficheros de log, generando dichos
ficheros (de 16 MB cada uno) con normalidad en /var/lib/postgresql/8.3/main/pg_xlog y rotndolos a
partir del octavo que almacene.
Acto seguido crearemos el directorio /var/lib/postgresql/pg_xlog_archive, directorio donde archivaremos
(copiaremos) los ficheros WAL cuando lo necesitemos, y le daremos permisos para el usuario postgres:
mkdir --mode=700 /var/lib/postgresql/pg_xlog_archive
chown postgres:postgres /var/lib/postgresql/pg_xlog_archive
Por ltimo, indicaremos a PostgreSQL que escuche en todas las interfaces pues, por defecto, slo lo hace
en el localhost. Editamos el fichero /etc/postgresql/8.3/main/postgresql.conf y cambiamos la siguiente
directiva:
Tambin podemos restringirlo a 127.0.0.1 y la direccin IP administrativa del nodo (192.168.0.3 en el

primer nodo, 192.168.0.4 en el segundo) para asegurarnos de que no est escuchando en la direccin IP
de servicio del clster (la 192.168.0.2, que queremos utilizar nicamente para pgpool-II).
Y reiniciamos PostgreSQL para activar los cambios:
/etc/init.d/postgresql-8.3 restart
Configuracin de pgpool-II
La configuracin de pgpool-II la realizaremos nicamente en el nodo pgsql1, pues slo en ese host lo
tenemos instalado.
pgpool-II proporciona una interfaz de gestin desde la cul el administrador puede recoger el estado de
pgpool-II y finalizar los procesos de pgpool-II a travs de la red. El fichero pcp.conf es un fichero de
nombres de usuario y contraseas usado para autenticarse con la interfaz. Todos los comandos requieren
que pcp.conf se haya configurado. Tras la instalacin de pgpool-II se crea un fichero
/opt/pgpool2/etc/pcp.conf.sample de ejemplo. Configurar ese fichero es tan sencillo como cambiarle el
nombre al fichero y aadir el usuario y contrasea deseados.
Por lo tanto, copiaremos el fichero de ejemplo a fichero deseado:
cp --archive /opt/pgpool2/etc/pcp.conf.sample /opt/pgpool2/etc/pcp.conf
Y lo editaremos para aadir nuestro usuario y contrasea en el formato:
usuario:
En este artculo se usar root como nombre de usuario. Para generar la suma MD5 de nuestra contrasea
podemos usar la utilidad pg_md5:
/opt/pgpool2/bin/pg_md5 -p
password: <password>
34b339799d540a72bf1c408c0e68afdd
Luego creamos un fichero de configuracin para pgpool-II a partir del que viene como ejemplo:
cp --archive /opt/pgpool2/etc/pgpool.conf.sample /opt/pgpool2/etc/pgpool.conf
Deberemos editar el fichero para configurarlo a nuestra medida. Para este artculo se configurarn las
siguientes funcionalidades:
Pool de conexiones.
Replicacin.
Balanceo de carga.
Empezaremos con una configuracin bsica para arrancar pgpool-II e iremos aadiendo funcionalidades.
Editamos el fichero /opt/pgpool2/etc/pgpool.conf para dejarlo tal y como sigue:
port = 9999
pcp_port = 9898
socket_dir = '/var/run/postgresql'
pcp_socket_dir = '/var/run/postgresql'
backend_socket_dir = '/var/run/postgresql'
pcp_timeout = 10
num_init_children = 32
max_pool = 4
child_life_time = 300
connection_life_time = 0
child_max_connections = 0
client_idle_limit = 0
authentication_timeout = 60
logdir = '/var/run/postgresql'
replication_mode = false
load_balance_mode = false
replication_stop_on_mismatch = false
replicate_select = false
reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'
print_timestamp = true
master_slave_mode = false
connection_cache = true
health_check_timeout = 20
health_check_period = 60
health_check_user = 'pgpool2'
failover_command = ''
failback_command = ''
insert_lock = false
ignore_leading_white_space = true
log_statement = false
log_connections = false
log_hostname = false
parallel_mode = false
enable_query_cache = false
pgpool2_hostname = 'pgsql1'
system_db_hostname = 'localhost'
system_db_port = 5432
system_db_dbname = 'pgpool'
system_db_schema = 'pgpool_catalog'
system_db_user = 'pgpool'
system_db_password = ''
backend_hostname0 = '192.168.0.3'
backend_port0 = 5432
backend_weight0 = 1
backend_port1 = 5432
backend_weight1 = 1
enable_pool_hba = false
recovery_user = 'pgpool2'
recovery_password = ''
recovery_1st_stage_command = ''
recovery_2nd_stage_command = ''
recovery_timeout = 90
Todas las directivas de configuracin vienen explicadas en la pgina web de pgpool-II. Como aspectos a
destacar de la anterior configuracin tenemos los siguientes:
Mediante la directiva listen_addresses hacemos que, inicialmente, pgpool-II escuche en todas las
interfaces.
Mediante las directivas logdir, socket_dir, pcp_socket_dir y backend_socket_dir, configuramos,
respectivamente, que el pid y todos los sockets de los diferentes procesos que forman pgpool-II
se guarden en el directorio por defecto de Debian para PostgreSQL, /var/run/postgresql.
Activamos el pool de conexiones (directiva connection_cache) pero dejamos todas las dems
funcionalidades desactivadas (replication_mode, load_balance_mode, replicate_select y
master_slave_mode).
Mediante las directivas health_check_timeout, health_check_period y health_check_user,
configuramos la comprobacin de estado de los servidores PostgreSQL para que se haga con el
usuario de base de datos pgpool2, cada 60 segundos y con un tiempo mximo de espera de 20
segundos.
Dejamos todos los lmites de conexiones, nmero de procesos, tiempos de espera y similares a
sus valores por defecto.
El siguiente paso ser crear el script de arranque de pgpool-II, que situaremos en

/opt/pgpool2/etc/init.d/pgpool2. A continuacin se muestra un tpico script, basado en el original del
paquete pgpool de Debian:
#! /bin/sh
PATH=/opt/pgpool2/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/opt/pgpool2/bin/pgpool
PIDFILE=/var/run/postgresql/pgpool.pid
test -x $DAEMON || exit 0
# Include pgpool defaults if available
if [ -f /opt/pgpool2/etc/default/pgpool2 ] ; then
. /opt/pgpool2/etc/default/pgpool2
fi
OPTS=""
if [ x"$PGPOOL_LOG_DEBUG" = x"yes" ]; then
OPTS="$OPTS -d"
fi
. /lib/lsb/init-functions
is_running() {
pidofproc -p $PIDFILE $DAEMON >/dev/null
d_start() {
if is_running; then
else
su -c "$DAEMON -n $OPTS 2>&1 </dev/null | logger -t pgpool -p ${PGPOOL_SYSLOG_FACILITY:-

local0}.info >/dev/null 2>&1 &" - postgres
fi
d_stop() {
killproc -p $PIDFILE $DAEMON -INT
status=$?
[ $status -eq 0 ] || [ $status -eq 3 ]
return $?
case "$1" in
start)
log_daemon_msg "Starting pgpool-II" pgpool
d_start
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping pgpool-II" pgpool
d_stop
log_end_msg $?
;;
status)
is_running
status=$?
if [ $status -eq 0 ]; then
log_success_msg "pgpool-II is running."
else
log_failure_msg "pgpool-II is not running."
fi
exit $status
;;
restart|force-reload)
log_daemon_msg "Restarting pgpool-II" pgpool
d_stop && sleep 1 && d_start

log_end_msg $?
;;
try-restart)
if $0 status >/dev/null; then
$0 restart
else
exit 0
fi
;;
reload)
exit 3
;;
*)
log_failure_msg "Usage: $0 {start|stop|status|restart|try-restart|reload|force-reload}"
exit 2
;;
esac
Siguiendo el estndar Debian, crearemos el fichero /opt/pgpool2/etc/default/pgpool2 con los valores de

configuracin de arranque del daemon. Opcionalmente, aprovechamos para ponerlo en modo debug al
arrancar:
# Defaults for pgpool initscript
# sourced by /opt/pgpool2/etc/init.d/pgpool2
# syslog facility for pgpool; see logger(1)
PGPOOL_SYSLOG_FACILITY=local0
# set to "yes" if you want to enable debugging messages to the log
PGPOOL_LOG_DEBUG=no
Ahora ya deberamos de ser capaces de arrancar pgpool-II:
/opt/pgpool2/etc/init.d/pgpool2 start
Podremos observar el correcto arranque del daemon (o los errores en caso contrario) monitorizando el
syslog, por ejemplo mediante el uso del comando tail:
/usr/bin/tail -f /var/log/syslog | ccze
A partir de este momento deberamos de ser capaces de conectarnos al puerto 9999 de la direccin IP de
administracin del nodo pgsql1 (la direccin IP de servicio no estar disponible hasta que configuremos la
alta disponibilidad con Heartbeat):
/usr/bin/psql -h pgsql1 -p 9999 -U pgpool2 -d postgres
Si deseamos monitorizar las conexiones a los nodos de PostgreSQL, podemos activar las directivas
log_connections y log_disconnections en los ficheros de configuracin
/etc/postgresql/8.3/main/postgresql.conf de cada nodo, reiniciando PostgreSQL para que los cambios
surjan efecto.
Debido a que no tenemos ni replicacin ni balanceo de carga activados , pgpool-II slo se habr
conectado al servidor PostgreSQL del nodo maestro, hecho que habremos podido comprobar
monitorizando el fichero de log de PostgreSQL en /var/log/postgresql/postgresql-8.3-main.log.
Tras haber comprobado que ya podemos conectarnos, vamos a proceder a activar la replicacin y el
balanceo de carga editando el fichero /opt/pgpool2/etc/pgpool.conf y cambiando las directivas siguientes:
replication_mode = true
load_balance_mode = true
replication_stop_on_mismatch = true
Para activar los cambios reiniciaremos pgpool-II:
/opt/pgpool2/etc/init.d/pgpool2 restart
Pruebas de replicacin
En el paquete postgresql-contrib-8.3 podemos encontrar una utilidad llamada pgbench. Esta utilidad
permite, en primer lugar, inicializar una base de datos con una serie de tablas sencillas y, en segundo
lugar, realizar pruebas de rendimiento sobre servidores PostgreSQL mediante la ejecucin de una cierta
cantidad de consultas de varios tipos y con una concurrencia parametrizable.
A partir de este momento trabajaremos desde un tercer equipo, actuando ya como cliente del clster. Por
comodidad, daremos de alta las entradas del fichero /etc/hosts mencionadas anteriormente en el artculo,
igual que hicimos en ambos nodos del clster. El primer paso consistir en crear la base de datos
bench_replication:
createdb -h pgsql1 -p 9999 -U pgpool2 bench_replication
createlang -h pgsql1 -p 9999 -U pgpool2 -d bench_replication plpgsql
Con log_statement y log_connections activados en /opt/pgpool2/etc/pgpool2.conf, sto nos mostrar

entradas en /var/log/syslog similares a las siguientes:
LOG: pid 4365: connection received: host=192.168.0.5 port=38024
LOG: pid 4365: statement: CREATE DATABASE bench_replication;
LOG: pid 4365: statement: RESET ALL
LOG: pid 4365: statement: SET SESSION AUTHORIZATION DEFAULT
Con log_statement = 'all' en /etc/postgresql/8.3/main/postgresql.conf, en el log de cualquiera de los

PostgreSQL nos aparecern las siguientes lneas:
LOG: connection received: host=192.168.0.3 port=33690
LOG: connection authorized: user=pgpool2 database=postgres
LOG: statement: CREATE DATABASE bench_replication;
LOG: statement: RESET ALL
LOG: statement: SET SESSION AUTHORIZATION DEFAULT
Como usuario postgres, en ambos nodos podremos usar psql para ver las bases de datos y verificar que
se han creado:
$ su - postgres
$ psql -l
List of databases
Name | Owner | Encoding
-------------------+----------+-----------
bench_replication | pgpool2 | SQL_ASCII
postgres | postgres | SQL_ASCII

template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
(4 rows)
Vamos a proceder ahora a rellenar las bases de datos con tablas e informacin de pruebas mediante el
uso de pgbench:
/usr/lib/postgresql/8.3/bin/pgbench -i -h pgsql1 -p 9999 -U pgpool2 -d bench_replication
En el syslog podremos ver la siguiente informacin:
LOG: pid 4363: connection received: host=192.168.0.5 port=38124
LOG: pid 4363: statement: SET search_path = public
LOG: pid 4363: statement: drop table if exists branches
LOG: pid 4363: statement: create table branches(bid int not null,bbalance int,filler char(88)) with (fillfactor=100)
LOG: pid 4363: statement: drop table if exists tellers
LOG: pid 4363: statement: create table tellers(tid int not null,bid int,tbalance int,filler char(84)) with (fillfactor=100)
LOG: pid 4363: statement: drop table if exists accounts
LOG: pid 4363: statement: create table accounts(aid int not null,bid int,abalance int,filler char(84)) with (fillfactor=100)
LOG: pid 4363: statement: drop table if exists history
LOG: pid 4363: statement: create table history(tid int,bid int,aid int,delta int,mtime timestamp,filler char(22))
LOG: pid 4363: statement: begin
LOG: pid 4363: statement: insert into branches(bid,bbalance) values(1,0)
LOG: pid 4363: statement: insert into tellers(tid,bid,tbalance) values (1,1,0)
LOG: pid 4363: statement: commit
LOG: pid 4363: statement: begin
LOG: pid 4363: statement: truncate accounts
LOG: pid 4363: statement: copy accounts from stdin
LOG: pid 4363: statement: commit
LOG: pid 4363: statement: alter table branches add primary key (bid)
LOG: pid 4363: statement: alter table tellers add primary key (tid)
LOG: pid 4363: statement: alter table accounts add primary key (aid)
LOG: pid 4363: statement: vacuum analyze
LOG: pid 4363: statement: RESET ALL
LOG: pid 4363: statement: SET SESSION AUTHORIZATION DEFAULT
Con un sencillo script vamos a contar el nmero de registros insertados en cada instancia de PostgreSQL
sin pasar por pgpool-II, de modo que podamos verificar que la replicacin se ha realizado correctamente:
#!/bin/sh
PGSQL=/usr/bin/psql
HEAD=/usr/bin/head
TAIL=/usr/bin/tail
CUT=/usr/bin/cut
IP_LIST="192.168.0.3 192.168.0.4"
PORT=5432
for ip in $IP_LIST
do
echo "ip address: $ip"
for t in branches tellers accounts history
do
echo -n "table $t: "
COUNT=`$PGSQL -h $ip -p $PORT -U pgpool2 -d bench_replication -c "SELECT count(*) FROM $t" | $HEAD -n 3 | $TAIL -n
1`
echo $COUNT
done
done
exit 0
Para poder ver cmo se balancean las consultas, teniendo activada la directiva log_statement = 'all' en
/etc/postgresql/8.3/main/postgresql.conf de ambos PostgreSQL, podemos utilizar el siguiente script para
ver qu consultas aparecen en el log de cada nodo:
#!/bin/sh
PGSQL=/usr/bin/psql
HEAD=/usr/bin/head
TAIL=/usr/bin/tail
CUT=/usr/bin/cut
IP_LIST="192.168.0.3"
PORT=9999
for ip in $IP_LIST
do
echo "ip address: $ip"
for t in branches tellers accounts history
do
echo -n "table $t: "
COUNT=`$PGSQL -h $ip -p $PORT -U pgpool2 -d bench_replication -c "SELECT count(*) FROM $t" | $HEAD -n 3 | $TAIL -n
1`
echo $COUNT
done
done
exit 0
En media, deberan haberse ejecutado dos (de las cuatro) consultas SELECT en cada una de las bases de
datos, si bien esto no tiene porqu ser siempre as.
A continuacin pasaremos a ejecutar el benchmark bsico de pgbench, de modo que podamos apreciar el
comportamiento del clster bajo continuas inserciones, actualizaciones y consultas. Desde la consola
ejecutaremos:
/usr/lib/postgresql/8.3/bin/pgbench -h pgsql1 -p 9999 -U pgpool2 -d bench_replication -c 10 -t 1000
El resultado obtenido ser similar al siguiente:
[..]
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 119.105754 (including connections establishing)
tps = 126.179781 (excluding connections establishing)
Si monitorizamos el log de pgpool-II en /var/log/syslog y los logs de ambas instancias de PostgreSQL,

veremos como en el primer nodo se ejecutan todas las consultas (update, select, update, update, insert)
mientras que en el segundo slo las insert y las update. Esto se debe a que cada transaccin est
explcitamente declarada (BEGIN...END) y, en ese caso, pgpool-II no hace uso ms que del nodo
principal.
Recuperacin en lnea
El procedimiento de recuperacin en lnea de un nodo (del ingls, online recovery) permite volver a
conectar nodos cados al clster. Es requisito, por lo tanto, que el nodo est desconectado o cado (del
ingls, dettached) antes de ejecutar este procedimiento (ver comandos pcp ms adelante).
En trminos generales, el proceso de recuperacin sigue los siguientes pasos:
Activar el comando de archivado de ficheros WAL.

Modificar el fichero /etc/postgresql/8.3/main/postgresql.conf.
Recargar la configuracin de PostgreSQL.
Ejecucin de /opt/pgpool2/bin/pcp_recovery_node.
Primera fase: copia del directorio base.
Segunda fase: sincronizacin de cambios.
Tercera fase: arranque del nuevo servidor.
El Write-Ahead Log
A partir de su versin 8, PostgreSQL almacena todas las operaciones que alteran los datos y los
metadatos de la base de datos en forma de logs binarios en el directorio /var/lib/postgresql/8.3/pg_xlog.
Estos logs se escriben y sincronizan en disco antes de que se alteren los ficheros de las tablas (de ah su
nombre, Write-Ahead Log o WAL) y su funcin principal es la recuperacin a un estado consistente de
forma automtica (de ah su nombre, Point-In-Time Recovery o PITR) en caso de fallo del sistema por
rotura de un disco, muerte de un proceso, etc. Su funcionamiento es anlogo al del journaling de un
sistema de ficheros. Cada uno de estos ficheros tiene un tamao de 16 MB y PostgreSQL los rota y
reutiliza automticamente (almacena un mximo de 8 ficheros por defecto). El uso de estos logs binarios
viene activado por defecto en PostgreSQL, pero no su archivado (copia a otra ubicacin).
Debido a la forma en que se realiza la recuperacin en lnea de un nodo con pgpool-II, en realidad no es
necesario tener una copia de todos los ficheros del WAL que se vayan generando, de ah que se use un
comando nulo durante la operacin rutinaria del servidor. Adems, el archivado de ficheros del WAL
habitualmente supone un importante impacto en el rendimiento del servidor.
Para este artculo suponemos suficiente el uso de pg_dump una vez al da como mecanismo de copias de
seguridad de los datos, luego no se estar haciendo uso de WAL y PITR como mecanismo de backup, sino
que se utilizar nicamente para la recuperacin online de un nodo. Por lo tanto, durante la operacin
normal del clster, ste debe estar activo pero con un comando de archivado nulo que no haga copia
alguna de los ficheros de log rotados, tal que:
archive_mode = on
# archive_command = '/bin/cp %p /var/lib/postgresql/pg_xlog_archive/%f'
sto es as debido a que no puede activarse o desactivarse el uso de ficheros WAL por parte de
PostgreSQL sin reiniciar el servicio (accin que queremos evitar en la medida de lo posible), mientras que
cambiar el comando que se usa para el archivado de dichos ficheros requiere tan slo una solicitud de
recarga de la configuracin al daemon de PostgreSQL. Segn se especifica en la documentacin en lnea
de PostgreSQL, es necesario que todo comando de archivado devuelva el valor 0 en caso de ejecucin
correcta y cualquier otro valor en caso contrario, de ah que se haya optado por un simple "exit 0".
Procedimiento completo
Una vez introducidos los conceptos a utilizar, acto seguido se detalla el procedimiento completo de
restauracin de un nodo cado. Como paso previo activaremos el comando de archivado de ficheros WAL
en el nodo maestro. Para ello, editaremos el fichero de configuracin
/etc/postgresql/8.3/main/postgresql.conf y cambiaremos el valor de la directiva archive_command,
segn sigue:
archive_mode = on
# archive_command = 'exit 0'
archive_command = '/bin/cp %p /var/lib/postgresql/pg_xlog_archive/%f'
Luego solicitaremos al daemon de PostgreSQL que recargue la configuracin mediante el siguiente

comando:
/etc/init.d/postgresql-8.3 reload
En el nodo a recuperar, donde PostgreSQL debe estar parado, dejaremos la configuracin original
(comando de archivado nulo), pues no es necesario para una PITR. El siguiente paso es hacer una
llamada al comando pcp_recovery_node, tal que:
/opt/pgpool2/bin/pcp_recovery_node 5 pgsql1 9898 root 1
En este ejemplo, la llamada se efecta con los siguientes parmetros:
Un timeout de 5 segundos.
Sobre el puerto 9898.
Al primer nodo del clster, "pgsql1", actuando en estos momentos como maestro.
Solicitando la recuperacin del segundo nodo (el conteo empieza por el 0).
Debido a que parten de una llamada a un procedimiento almacenado de base de datos, todas las
acciones que se realizan a raz de esta llamada se ejecutan como usuario de sistema postgres. Divididas
en tres fases, se detallan a continuacin.
Primera fase
pgpool-II ejecuta SELECT pgpool_recovery('recovery_1st_stage_command', 'target', 'PGDATA') en un

nodo maestro. Esto produce una llamada al script /var/lib/postgresql/8.3/main/base-backup. Durante la
ejecucin de este script se siguen atendiendo peticiones de los clientes (que PostgreSQL ir almacenando
en su bitcora).
Los valores de los tres parmetros de la llamada se obtienen del fichero /opt/pgpool2/etc/pgpool.conf. El
primero de la directiva recovery_1st_stage_command; el segundo de la directiva backend_hostname
correspondiente al nodo a recuperar; y el tercero de la directiva backend_data_directory correspondiente
al nodo a recuperar.
En primer lugar, este script genera un fichero llamado recovery.conf, que sita dentro del directorio
PG_DATA (/var/lib/postgresql/8.3/main en Debian). Este fichero se crea en esa ubicacin para que sea
transferido al nodo a recuperar ms adelante en este mismo script. Cuando el servidor PostgreSQL del
nodo a recuperar arranque y realice una recuperacin PITR, leer ese fichero y ejecutar el valor de la
variable restore_commandtantas veces como sea necesario para obtener los ficheros WAL que le
permitirn llegar desde el punto en la bitcora donde finaliz la copia de seguridad online hasta el
momento en el cual se dejaron de atender peticiones (segunda fase de la recuperacin online de un
nodo). El origen de esos ficheros WAL ser el directorio /var/lib/postgresql/pg_xlog_archive del nodo
maestro, que es donde el comando de la directiva archive_command copia los ficheros WAL que se van
rotando.
Durante la ejecucin de este script, pgpool-II sigue antendiendo peticiones de los clientes, de ah que se
inicie un backup online de PostgreSQL antes de empezar la copia. De este modo, las diferencias entre
ambos nodos cuando el script haya terminado su ejecucin sern tan slo los ficheros WAL generados
durante su ejecucin, que habrn sido archivados en un directorio aparte
(/var/lib/postgresql/pg_xlog_archive) para evitar que ms de 8 rotaciones de logs durante la ejecucin
del script sobreescriban ficheros WAL (en el caso de mucha actividad en el servidor o de tener un
volumen de datos a copiar muy grande, o de ambas).
En segundo lugar, este script indica a PostgreSQL que se va a iniciar una copia de seguridad online
mediante la ejecucin de la consulta SELECT pg_start_backup('etiqueta') en un nodo maestro. Esto, a su
vez, fuerza un CHECKPOINT. Un checkpoint es un punto en la secuencia del log de transacciones a partir
del cual todos los ficheros de datos han sido actualizados para reflejar la informacin en el log o bitcora.
Todos los ficheros de datos sern escritos en disco. Un checkpoint acta como punto de inicio para una
recuperacin PITR. Es decir, un checkpoint ms un conjunto de ficheros WAL es todo lo que se necesita
para recuperar una base de datos PostgreSQL a un estado consistente, mediante el mecanismo de PITR.
En tercer lugar, el script realiza una copia del directorio /var/lib/postgresql/8.3/main desde el nodo
maestro al nodo a recuperar mediante el uso de varias sentencias rsync.
Por ltimo, el script indica a PostgreSQL que ya ha terminado el backup online mediante la ejecucin de
la sentencia SELECT pg_stop_backup(). Tras la anotacin del punto donde finaliza el backup, el puntero
de insercin del fichero de log actual se desplaza al siguiente fichero de log, de modo que el fichero
actual puede rotarse y archivarse, completndose as la copia de seguridad.
Segunda fase
Una vez finalizada la copia del directorio base, pgpool-II deja de atender las peticiones de los clientes,
quedando stas acumuladas en una cola de peticiones pendientes de atender, y finaliza las que
estuvieran en ejecucin (durante un tiempo mximo definido en la directiva
client_idle_limit_in_recovery).
Luego pgpool-II ejecuta SELECT pgpool_recovery('recovery_2nd_stage_command', 'target', 'PGDATA')en

un nodo maestro. Esto produce una llamada al script /var/lib/postgresql/8.3/main/pgpool-recovery-pitr.
Los valores de los tres parmetros de la llamada se obtienen del fichero /opt/pgpool2/etc/pgpool.conf. El
primero de la directiva recovery_2nd_stage_command; el segundo de la directiva backend_hostname
correspondiente al nodo a recuperar; y el tercero de la directiva backend_data_directory correspondiente
al nodo a recuperar.
Este script fuerza una rotacin de ficheros WAL mediante la ejecucin de la sentencia SQL SELECT
pg_switch_xlog(). Esta rotacin de ficheros WAL se realiza en este instante (tras haber dejado de atender
peticiones de clientes) a fin de generar un estado inalterado de la base de datos que pueda ser
recuperado por el nuevo nodo a partir del backup del directorio base ms los ficheros WAL generados por
sucesivas rotaciones desde el inicio del backup hasta esta ltima rotacin explcita).
Tercera fase
pgpool-II ejecuta SELECT pgpool_remote_start('target', 'PGDATA') en el nodo maestro. Esto produce una
llamada al script /var/lib/postgresql/8.3/main/pgpool_remote_start. Los valores de los dos parmetros de
la llamada se obtienen del fichero /opt/pgpool2/etc/pgpool.conf. El primero de la directiva
backend_hostname correspondiente al nodo a recuperar; y el segundo de la directiva
backend_data_directory correspondiente al nodo a recuperar. El nombre del script a recuperar est
incluido en el cdigo fuente del fichero /usr/local/src/pgpool-II-2.2.2/sql/pgpool-recovery y, si se desea
cambiar, debe alterarse antes de compilar e instalar.
Este script arranca PostgreSQL en el nodo que se est recuperando mediante una llamada al binario
/usr/bin/pg_ctlcluster, y PostgreSQL hace una recuperacin PITR al arrancar. El tiempo de espera para el
arranque no ser superior a lo que indique la directiva recovery_timeout (en segundos) del fichero
/opt/pgpool2/etc/pgpool.conf.
Una vez finalizado el proceso de PITR, el nodo de PostgreSQL recuperado acepta conexiones de nuevo.
pgpool-II se conecta al nuevo nodo y, a partir de este momento, el nodo forma parte del clster de
nuevo. El clster opera de nuevo con normalidad, todas las bases de datos son accesibles de nuevo y se
procesan las peticiones acumuladas durante la segunda y tercera fases de la recuperacin en lnea.
Pasos finales
Una vez finalizada la recuperacin, y habiendo comprobado el correcto funcionamiento del clster con su
nuevo nodo, procederemos a desactivar el comando de archivado de ficheros WAL del nodo maestro,
alterando el fichero de configuracin /etc/postgresql/8.3/main/postgresql.conf y dejando el valor nulo exit
0 del parmetro, tal y como estaba antes de iniciar el procedimiento y solicitaremos una recarga de la
configuracin.
En este momento, nuestro clster acaba de finalizar la operacin llamada failback, es decir, se ha
recuperado de una operacin de failover que se inici al detectar que uno de los nodos no estaba
disponible. pgpool-II permite configurar sendos scripts para que sean ejecutados al iniciarse y finalizar,
respectivamente, los eventos de failover y failback. Estas directivas se encuentran en el fichero de
configuracin /opt/pgpool2/etc/pgpool.conf y son las siguientes:
failover_command = ''
failback_command = ''
En el apartado siguiente se ofrecen ejemplos de scripts que realizan todas las tareas descritas
anteriormente.
Scripts necesarios
En este apartado se muestran varios scripts que son necesarios para realizar la recuperacin en lnea de
un nodo. La documentacin de pgpool-II describe los pasos especficos a seguir, que varan dependiendo
de la versin de PostgreSQL que estemos usando y de las herramientas de sistema de que dispongamos,
pero deja a discrecin del administrador de sistemas su implementacin. Como en muchos casos, no hay
una nica solucin que se ajuste a todos los casos.
Listados en orden de ejecucin, los scripts necesarios son los siguientes:
pgpool-failover
wall_archiving
base-backup
pgpool-recovery-pitr
pgpool_remote_start
pgpool-failback
Todos ellos deben residir en el directorio de datos de PostgreSQL (/var/lib/postgresql/8.3/main) de todos

los nodos.
El script wall_archiving lo ejecutaremos manualmente antes de empezar la recuperacin del nodo y tras
finalizar la misma, bien como usuario root, bien como usuario postgres.
Los scripts base-backup y pgpool-recovery-pitr reciben tres parmetros, en este orden:
1. Directorio de datos de origen ($PG_DATA).

2. Nombre del host a recuperar ($PG_HOST).
3. Directorio de datos de destino ($PG_DATA).
El script pgpool_remote_start recibe slo los dos ltimos. Los tres scripts se ejecutan en algn nodo
maestro del cual pgpool-II tenga constancia y est activo (conste como attached), y corren como usuario
postgres.
Por ltimo, los scripts pgpool-failover y pgpool-failback, tambin ejecutados como usuario postgres,
reciben un conjunto de parmetros, en el orden elegido por el usuario, de entre los siguientes:
%d: identificador de nodo.

%h: nombre del host.
%p: puerto.
%D: ruta al directorio de datos del clster
%m: identificador del nuevo nodo maestro.
%M: identificador del nodo maestro antiguo.
Para escapar el carcter de porcentaje (%) se usa otro porcentaje (%%).
Estos parmetros se configuran en la propia llamada al script deseado en la configuracin de pgpool-II

(fichero /opt/pgpool2/etc/pgpool.conf). Por ejemplo, para este artculo se configuraron de la siguiente
manera:
failover_command = '/var/lib/postgresql/8.3/main/pgpool-failover %d %h %p %D %m %M'
failback_command = '/var/lib/postgresql/8.3/main/pgpool-failback %d %h %p %D %m %M'
Los valores %m (identificador del nuevo nodo maestro) y %M (identificador del nodo maestro antiguo)
tienen mucho valor cuando el nodo que cae (durante un failover) es el nodo maestro y pgpool-II decide,
a partir de aquel momento, considerar otro nodo (antes esclavo) como nuevo nodo maestro.
En todos los casos, los parmetros pasados por pgpool-II al script que se est llamando se reciben como
parmetros de la manera habitual, tratndose como en cualquier otro caso y de la forma pertinente
dependiendo del lenguage de scripting utilizado.
wal_archiving
El proceso de activacin y desactivacin del comando de archivado puede automatizarse mediante scripts
de Bash, Perl o similar, e incluso integrarse dentro de la primera y ltima fases de la recuperacin. En
realidad, es una cuestin de gustos ms que otra cosa. Personalmente, prefiero tenerlos por separado y
ejecutarlos manualmente. A continuacin se muestra un script de Bash que realiza dicha funcin:
#!/bin/sh
SED=/bin/sed
PSQL=/usr/bin/psql
PGDIR="/etc/postgresql/8.3/main"
PGCONF="postgresql.conf"
UNAME=/bin/uname
HOST=`$UNAME -n`
test -x $PSQL || exit 0
test -f $PGDIR/$PGCONF || exit 0
case "$1" in
start)
echo -n "Activating WAL archiving: "
$SED -r -e "s/\s*archive_command\s*=.*/archive_command = '\/bin\/cp %p \/var\/lib\/postgresql\/pg_xlog_archive\/

%f'/" $PGDIR/$PGCONF > /tmp/$PGCONF
chmod 644 /tmp/$PGCONF
mv --force /tmp/$PGCONF $PGDIR/
/etc/init.d/postgresql-8.3 reload 2>&1 > /dev/null
echo "done."
;;
stop)
echo -n "Deactivating WAL archiving: "
$SED -r -e "s/\s*archive_command\s*=.*/archive_command = 'exit 0'/" $PGDIR/$PGCONF > /tmp/$PGCONF
chmod 644 /tmp/$PGCONF
mv --force /tmp/$PGCONF $PGDIR/
/etc/init.d/postgresql-8.3 reload 2>&1 > /dev/null
echo "done."
;;
status)
# Alternate way: SELECT setting FROM pg_settings WHERE name = 'archive_command'
am=`$PSQL -t -U pgpool2 -h $HOST -d postgres -c 'SHOW archive_mode' | $SED -r -e 's/^\s*//;s/\s*$//'`
ac=`$PSQL -t -U pgpool2 -h $HOST -d postgres -c 'SHOW archive_command' | $SED -r -e 's/^\s*//;s/\s*$//'`
echo "archive_mode = $am"
echo "archive_command = '$ac'"
;;
*)
echo "Usage: $0 {start|stop|status}"
exit 1
;;
esac
exit 0
Este script podra crearse en /var/lib/postgresql/8.3/main/wall_archiving (propiedad del usuario y grupo

postgres y permisos 755) sera llamado como usuario root o postgres pasndole por parmetro start,
stop o status. Por ejemplo:
$ /var/lib/postgresql/8.3/main/wall_archiving
Usage: /var/lib/postgresql/8.3/main/wall_archiving {start|stop|status}
$ /var/lib/postgresql/8.3/main/wal_archiving status
archive_mode = on
$ /var/lib/postgresql/8.3/main/wal_archiving start
Activating WAL archiving: done.
$ /var/lib/postgresql/8.3/main/wal_archiving stop
Deactivating WAL archiving: done.
$ tail -n 2 /var/log/postgresql/postgresql-8.3-main.log | ccze -A
LOG: incomplete startup packet
LOG: received SIGHUP, reloading configuration files
pgpool-failover
En trminos generales, el mecanismo de failover permite asegurar la alta disponibilidad de diversos

recursos crticos (como un sistema informtico o un servicio de un sistema) incluyendo un sistema de
respaldo paralelo que se mantiene en ejecucin en todo momento, de modo que, en caso de detectarse
un fallo en el sistema primario, las tareas a procesar puedan ser automticamente desviadas hacia el
sistema de respaldo, que seguir dando servicio a los clientes.
En este artculo se configura un clster activo-pasivo (primario-secundario), con la salvedad de que se

hace uso tambin del nodo secundario de forma parcial para acelerar las consultas de tipo SELECT
(balanceo de carga). El procedimiento de failover en pgpool-II puede suponer tanto un failover hacia el
nodo secundario (si ha fallado el primario) como una degeneracin del nodo secundario (desactivacin del
nodo de respaldo).
En el caso de haber ms de un nodo secundario, lo arriba expuesto no vara pues slo hay un nodo
maestro. El siguiente script enva dos entradas al syslog, que luego pueden ser capturadas por una
herramienta de monitorizacin como Zabbix o Nagios, las cuales enviaran las alertas pertinentes. Este es
un acercamiento que utilizo normalmente, alternativo al tradicional envo de una notificacin por correo
electrnico.
#! /bin/sh
LOGGER="/usr/bin/logger -i -p local0.info -t pgpool"
BASENAME=`/usr/bin/basename $0`
ID=`/usr/bin/id -un`
# $1 = node id
# $2 = host name
# $3 = port number
# $4 = database cluster path

# $5 = new master node id
# $6 = old master node id
$LOGGER "Executing $BASENAME as user $ID"
$LOGGER "Failover of node $1 at hostname $2. New master node is $5. Old master node was $6."
exit 0
pgpool-II ejecuta este script como usuario postgres al final del proceso, una vez se ha completado la
degeneracin del nodo.
pgpool-failback
Anlogamente, failback es el proceso mediante el cual se devuelve un sistema, componente o servicio en

un estado de failover a su estado original (antes del fallo).
pgpool-II ejecuta el script configurado como usuario postgres una vez concluido el procedimiento de
failback, es decir, la recuperacin en lnea de un nodo en tres pasos. Del mismo modo que el caso del
failover, a continuacin se muestra un sencillo script de Bash que aade una entrada al syslog, de modo
que pueda ser capturada por una herramienta de monitorizacin de logs que enve las alertas
pertinentes.
#! /bin/sh
# $1 = node id
# $2 = host name
# $3 = port number
# $4 = database cluster path
# $5 = new master node id
# $6 = old master node id
$LOGGER "Failback of node $1 at hostname $2. New master node is $5. Old master node was $6."
exit 0
base-backup
De entre todas las tareas a realizar por parte del script base-backup, la nica que est sujeta a variacin
en su implementacin es la copia inicial de todo el directorio de datos de PostgreSQL ($PG_DATA, que en
Debian es /var/lib/postgresql/8.3/main) desde el nodo maestro al nodo a recuperar.
En el caso del script que se presenta a continuacin, la herramienta elegida es rsync sobre un tnel SSH
con un par de claves pblica/privada DSA de 1024 bits sin contrasea. Esta eleccin se basa en dos
puntos:
La eficiencia de rsync (impacto sobre los discos frente al tiempo necesario), si bien el uso de un
canal cifrado ralentiza el proceso.
La mayor parte de los datos a copiar ya existirn en el nodo a recuperar. Podemos considerar que
esta premisa ser falsa nicamente en el caso de que el motivo de la cada del nodo hubiera sido
la rotura de los discos.
A continuacin se presenta un script de ejemplo:
#!/bin/sh
PSQL=/usr/bin/psql
SCP=/usr/bin/scp
SSH=/usr/bin/ssh
RSYNC="/usr/bin/rsync --archive --quiet --compress --rsh=$SSH --delete"
HOSTNAME=`/bin/hostname`
# $1 = Database cluster path of a master node.
# $2 = Hostname of a recovery target node.
# $3 = Database cluster path of a recovery target node.
PG_HOME=/var/lib/postgresql
SRC_DATA=$1
DST_HOST=$2
DST_DATA=$3
$LOGGER "Executing pg_start_backup"
$PSQL -d postgres -c "select pg_start_backup('pgpool-recovery')"
$LOGGER "Creating file recovery.conf"
echo "restore_command = '$SCP $HOSTNAME:$PG_HOME/pg_xlog_archive/%f %p'" > $SRC_DATA/recovery.conf
$LOGGER "Rsyncing directory base"
$RSYNC $SRC_DATA/base/ $DST_HOST:$DST_DATA/base/
$LOGGER "Rsyncing directory global"
$RSYNC $SRC_DATA/global/ $DST_HOST:$DST_DATA/global/
$LOGGER "Rsyncing directory pg_clog"
$RSYNC $SRC_DATA/pg_clog/ $DST_HOST:$DST_DATA/pg_clog/
$LOGGER "Rsyncing directory pg_multixact"
$RSYNC $SRC_DATA/pg_multixact/ $DST_HOST:$DST_DATA/pg_multixact/
$LOGGER "Rsyncing directory pg_subtrans"
$RSYNC $SRC_DATA/pg_subtrans/ $DST_HOST:$DST_DATA/pg_subtrans/
$LOGGER "Rsyncing directory pg_tblspc"
$RSYNC $SRC_DATA/pg_tblspc/ $DST_HOST:$DST_DATA/pg_tblspc/
$LOGGER "Rsyncing directory pg_twophase"
$RSYNC $SRC_DATA/pg_twophase/ $DST_HOST:$DST_DATA/pg_twophase/
$LOGGER "Rsyncing directory pg_xlog"
$RSYNC $SRC_DATA/pg_xlog/ $DST_HOST:$DST_DATA/pg_xlog/

$LOGGER "Rsyncing file recovery.conf (with source deletion)"
$RSYNC --remove-source-files $SRC_DATA/recovery.conf $DST_HOST:$DST_DATA/
$LOGGER "Executing pg_stop_backup"
$PSQL -d postgres -c 'select pg_stop_backup()'
exit 0
pgpool-recovery-pitr
El nico propsito de este script es forzar la rotacin de un fichero WAL (y su consecuente archivado al
directorio /var/lib/postgresql/pg_xlog_archive). El script pgpool-recovery-pitr se ejecuta una vez se han
dejado de atender nuevas peticiones de clientes (que quedan en una cola de peticiones pendientes de
atender) y se han atendido las que estaban en curso (o se ha llegado al timeout y se han desechado).
A continuacin se presenta un script de ejemplo:
#! /bin/sh
PSQL=/usr/bin/psql
$LOGGER "Executing pg_switch_xlog"
$PSQL -d postgres -c 'select pg_switch_xlog()'
exit 0
pgpool_remote_start
La funcin del script pgpool_remote_start es la de arrancar remotamente la instancia de PostgreSQL en el

nodo a recuperar. Para poder utilizar el mismo usuario postgres y su par de claves pblica/privada, he
optado por hacer una llamada a travs de SSH directamente al binario /usr/bin/pg_ctlcluster. Ntese que
el script de arranque sito en /etc/init.d/postgresql-8.3 realiza la misma llamada, pero precedida de una
serie de verificaciones que, en este caso, asumimos como correctas (bsicamente que se dispone de
todos los binarios y libreras necesarios y que no hay una instancia ya ejecutndose):
#! /bin/sh
SSH=/usr/bin/ssh
DST_HOST=$1
DST_DIR=$2
$LOGGER "Starting remote PostgreSQL server"

$SSH -T $DST_HOST '/usr/bin/pg_ctlcluster 8.3 main start' 2>/dev/null 1>/dev/null
exit 0
Comandos de PCP
pgpool-II proporciona una interfaz de control desde la consola mediante la cual el administrador puede
recoger el estado de pgpool-II y gestionar sus procesos a travs de la red. Todos los comandos PCP
siguen el mismo patrn:
<comando_pcp> <timeout> <hostname> <puerto> <username> <password> [<nm_nodo>]
El nmero de nodo es necesario slo en algunos comandos. Todos los comandos se encuentran en
/opt/pgpool2/bin, por lo que se eliminar esta ruta en todos los ejemplos (queda a discrecin del usuario
aadir dicho directorio al PATH o preceder los comandos con la misma). El hostname ser siempre el de
la mquina donde se est ejecutando pgpool-II y el puerto el 9898. El usuario y la contrasea sern los
definidos en el fichero /opt/pgpool2/etc/pcp.conf.
A continuacin se muestra el funcionamiento de algunos de estos comandos, utilizados para la gestin del
clster explicado en el artculo.
Para saber el nmero de nodos controlados por pgpool-II (activos o no), podemos ejecutar el siguiente
comando:
pcp_node_count 5 pgsql1 9898 root <password>
Nos devolver un nmero entero mayor o igual que cero. Es til a la hora de crear scripts. Para saber el
estado de un nodo podemos usar el siguiente comando:
pcp_node_info 5 pgsql1 9898 root <password> <nm_nodo>
El ltimo parmetro ser el nmero de nodo del cul se desea informacin. Tngase en cuenta que se
empieza a contar por el cero. La salida del comando ofrece cuatro campos, en este orden:
1. Nombre del host

2. Nmero de puerto
3. Estado
4. Peso en el balanceo de carga
El estado viene representado por un dgito de 0 a 3:
0. Este estado se usa nicamente durante la inicializacin y PCP no lo mostrar nunca.

1. El nodo est activo pero no ha recibido conexiones todava.
2. El nodo est activo y hay conexiones activas (en el pool o fondo comn).
3. El nodo est cado.
eoferr 2 error de fin de fichero (end of file)
nomemerr 3 memoria insuficiente
readerr 4 error durante la lectura de datos del servidor
writeerr 5 error durante la escritura de datos al servidor
timeouterr 6 timeout
invalerr 7 parmetros del comando pcp incorrectos
connerr 8 error de conexin con el servidor
noconnerr 9 no existe ninguna conexin
sockerr 10 error de socket
hosterr 11 error de resolucin del nombre de host
backenderr 12 error de proceso de pcp en el servidor (se especific un id invlido, etc.)
autherr 13 error de autorizacin
Simulacin de cada y recuperacin de un nodo
Para simular la cada de un nodo, vamos a apagar el servidor PostgreSQL del nodo secundario:
/etc/init.d/postgresql-8.3 stop
En estos instantes, lo ms probable es que pgpool-II an no se haya dado cuenta de que ese nodo est
cado. Bien podemos esperar a que se ejecute un health check (cada 60 segundos o segn se haya
configurado la directiva health_check_period) o podemos forzarlo manualmente lanzando una consulta
SQL de tipo INSERT, UPDATE o DELETE. En cualquier caso, veremos aparecer las siguientes lneas en el
/var/log/syslog:
ERROR: pid 27928: connect_inet_domain_socket: connect() failed: Connection refused
ERROR: pid 27928: health check failed. 1 th host 192.168.0.4 at port 5432 is down
LOG: pid 27928: set 1 th backend down status
LOG: pid 27928: starting degeneration. shutdown host 192.168.0.4(5432)
LOG: pid 27928: failover_handler: do not restart pgpool. same master node 0 was selected
LOG: pid 27928: failover done. shutdown host 192.168.0.4(5432)
Con la consulta SQL siguiente obtendremos el mismo resultado:
psql -h 192.168.0.4 -p 9999 -U pgpool2 -d bench_replication -c "UPDATE ACCOUNTS SET abalance = 1009 WHERE aid = 10"
Como puede observarse en el log, para llevar a cabo el proceso de failover, pgpool-II tan slo tiene que
degenerar el nodo cado y, tal y como informa, no es necesario reinicio alguno. A efectos prcticos, lo
nico que se ha perdido es la capacidad de balancear la carga. ste es el caso ms sencillo posible al que
podemos enfrentarnos.
Ahora, para iniciar la recuperacin del nodo pgsql2, realizaremos los siguientes pasos (segn lo explicado
anteriormente en este artculo):
1. Activar el archivado de ficheros WAL.

2. Ejecutar el comando pcp_recovery_node en el nodo 0 (pgsql1) o en algn cliente con autorizacin
en el fichero pg_hba.conf.
3. Desactivar el archivado de ficheros WAL y borrar aquellos que se hayan copiado al directorio
/var/lib/postgresql/pg_xlog_archive del nodo maestro durante el proceso.
El siguiente comando instruye a pgpool-II que inicie el proceso de recuperacin del nodo 1 (pgsql2):
/opt/pgpool2/bin/pcp_recovery_node 5 pgsql1 9898 root <password> 1

ste es el log de pgpool-II (/var/log/syslog) producido por la ejecucin del anterior comando (los
comandos de failover y failback no estaban configurados en el fichero de configuracin durante la
ejecucin):
LOG: pid 27964: starting recovering node 1
LOG: pid 27964: CHECKPOINT in the 1st stage done
LOG: pid 27964: starting recovery command: "SELECT pgpool_recovery('base-backup', '192.168.0.4', '/var/lib /postgresql/8.3/main')"
pgpool[28094]: Executing base-backup as user postgres
pgpool[28095]: Executing pg_start_backup
pgpool[28098]: Creating file recovery.conf
pgpool[28099]: Rsyncing directory base
pgpool[28103]: Rsyncing directory global
pgpool[28106]: Rsyncing directory pg_clog
pgpool[28109]: Rsyncing directory pg_multixact
pgpool[28112]: Rsyncing directory pg_subtrans
pgpool[28115]: Rsyncing directory pg_tblspc
pgpool[28118]: Rsyncing directory pg_twophase
pgpool[28121]: Rsyncing directory pg_xlog
pgpool[28124]: Rsyncing file recovery.conf (with source deletion)
pgpool[28127]: Executing pg_stop_backup
LOG: pid 27964: 1st stage is done
LOG: pid 27964: starting 2nd stage
LOG: pid 27964: all connections from clients have been closed
LOG: pid 27964: CHECKPOINT in the 2nd stage done
LOG: pid 27964: starting recovery command: "SELECT pgpool_recovery('pgpool-recovery-pitr', '192.168.0.4',

'/var/lib/postgresql/8.3/main')"
pgpool[28138]: Executing pgpool-recovery-pitr as user postgres
pgpool[28147]: Executing pgpool_remote_start as user postgres
pgpool[28148]: Starting remote PostgreSQL server
LOG: pid 27964: 1 node restarted
LOG: pid 27964: send_failback_request: fail back 1 th node request from pid 27964
LOG: pid 27964: recovery done
LOG: pid 27928: starting fail back. reconnect host 192.168.0.4(5432)
LOG: pid 27928: failover_handler: do not restart pgpool. same master node 0 was selected
LOG: pid 27928: failback done. reconnect host 192.168.0.4(5432)
Tal y como podemos ver en el log, pgpool-II realiza las siguientes acciones:
Hace un checkpoint de la base de datos. Este checkpoint en realidad no es necesario, pues ya lo

lanza el propio pg_start_backup que se ejecuta al principio del script base-backup, pero est aqu
por compatibilidad con PostgreSQL 7.4.
Ejecuta el script base-backup (primera fase de la recuperacin en lnea) mediante la ejecucin de
la funcin pgpool_recovery aadida durante la configuracin de pgpool-II. Durante la ejecucin de
este fichero, sigue aceptando y atendiendo peticiones de los clientes.
Corta las nuevas conexiones de clientes, que quedan encoladas, a la espera de poder ser
atendidas.
Espera a que se hayan atendido las peticiones que ya estaban en marcha.
Realiza un checkpoint en la base de datos (pone fin al backup online).
Ejecuta el script pgpool-recovery-pitr (segunda fase de la recuperacin en lnea), tambin
mediante la funcin pgpool_recovery. Esto fuerza la rotacin del fichero WAL actual.
Ejecuta el script pgpool_remote_start.
Reconoce el nuevo nodo y lo aade al clster.
Vuelve a operar con normalidad, atendiendo a las peticiones que se haban ido encolando durante
la segunda fase y el inicio remoto del nuevo nodo.
En el caso de que se hayan producido variaciones de los datos durante la primera fase de la
recuperacin (se hayan atendido consultas INSERT, UPDATE o DELETE), ser necesario ejecutar
REINDEX sobre todos los ndices de la base de datos afectados una vez recuperado el nodo,
puesto que las operaciones sobre ndices de tipo tablas de dispersin (hash) no se guardan en el
WAL.
Si realizamos la misma operacin con el nodo principal, el proceso de failover consistir en la
degeneracin del nodo principal y en cambiar el papel de maestro al nodo pasivo del clster (a
partir de ahora el nodo maestro ser el 1). Tras realizar la recuperacin online, pgpool-II
mantendr al nodo secundario como maestro.
Alta disponibilidad de pgpool-II

Gracias a pgpool-II tenemos la posibilidad de seguir dando servico tras el fallo de N-1 servidores de
PostgreSQL en nuestro clster. Ahora bien, si la alta disponibilidad completa es uno de los requerimientos
(u objetivos) de nuestro sistema, debemos garantizar la continuidad del servicio en caso de cada del
middleware.
Para ello, instalaremos otra copia de pgpool-II en el nodo pgsql2, con una configuracin casi idntica a la
del ya instalado, y utilizaremos Heartbeat para detectar la cada completa de un nodo (no slo del
servidor de PostgreSQL en dicho nodo) y la gestin de dicho evento. A partir de este momento, entra en
juego una nueva direccin IP, la 192.168.0.2, que es la direccin IP que ambos nodos compartirn y que
Heartbeat se encargar de gestionar, de modo que slo uno de los nodos (aquel actuando como maestro)
tenga configurada dicha direccin IP en un momento dado. Esta direccin IP es conocida como direccin
IP de servicio.
Los pasos a seguir para instalar pgpool-II en pgsql2 son los mismos que en pgsql1:
Bajar los fuentes al directorio /usr/local/src.

Instalar las dependencias de compilacin.
Descomprimir, compilar e instalar.
Compilar e instalar la funcin y la librera
pgpool-recovery
Crear los ficheros de configuracin y el script de arranque.
Los ficheros de configuracin y el script de arranque pueden copiarse desde pgsql1 a pgsql2. El nico
fichero que precisar algunas modificaciones ser /opt/pgpool2/etc/pgpool.conf. A continuacin se
presentan los valores que habr que cambiar en pgsql2:
listen_addresses = '192.168.0.2'
pgpool2_hostname = 'pgsql2'
Y en el nodo pgsql1 tan slo habr que cambiar la direccin IP de servicio:
[cdigo 58]
Hay que tener en cuenta que, si en algn momento el nodo pgsql2 pasase a ser el nodo maestro,
entonces los ndices de los nodos se invertiran, ya que en el pgpool-II de pgsql2 los nodos estn
configurados al revs (pgsql1 pasara a ser el nodo 1 y pgsql2 sera el nodo 0).
El proyecto Linux High Availability
El objetivo fundamental del proyecto Linux-HA es desarrollar una solucin de alta disponibilidad
(clustering) para Linux que proporcione y promocione la fiabilidad, la disponibilidad y la calidad de
servicio o usabilidad (RAS, en sus siglas en ingls) a travs del esfuerzo de una comunidad de
desarrolladores.
El programa Heartbeat es uno de los componentes principales del proyecto. Fcilmente portable, corre en
todos los Linux conocidos, as como en FreeBSD y Solaris. Heartbeat es una de las implementaciones
principales del estndar Open Cluster Framework (OCF).
Heartbeat fue la primera pieza de software que se escribi para el proyecto Linux-HA. Puede llevar a cabo
la deteccin de la cada de nodos, las comunicaciones y la gestin del clster en un solo proceso.
Actualmente soporta un modelo de dependencias muy sofisticado para clsteres de N nodos, y es muy
til y estable. La unidad de gestin de Heartbeat es el recurso. Los recursos pueden ser, por ejemplo,
direcciones IP o servicios (aplicaciones). Los siguientes tipos de aplicaciones son tpicos ejemplos:
Servidores de bases de datos.

Servidores web.
Aplicaciones ERP.
Servidores de correo electrnico.
Cortafuegos.
Servidores de ficheros.
Servidores de DNS.
Servidores de DHCP.
Servidores de proxy-cach.
Un recurso es la unidad bsica de la alta disponibilidad. Un recurso es un servicio o facility el cul pasa a
tener alta disponibilidad mediante el gestor de recursos del clster de alta disponibilidad.
Un recurso es una abstraccin que puede ser de diferentes tipos. Puede ser algo muy concreto, como un
volumen de disco o un lector de tarjetas, o puede ser ms abstracto, como una direccin IP, un conjunto
de reglas de firewall o un servicio de software (como un servidor web o un servidor de base de datos).
Las operaciones bsicas que los recursos deben soportar son las siguientes:
start: iniciar o adquirir el control del recurso.

stop: finalizar o ceder el control del recurso.
status: consultar si el recurso est iniciado o parado.
monitor: consultar de manera ms detallada si el recurso est operando correctamente.
Ntese que los recursos del tipo R1 (versin 1 de Linux-HA) deben soportar status, mientras que los del
tipo R2 (versin 2) deben soportar la operacin monitor.
El gestor de recursos del clster de alta disponibilidad intenta conseguir que todos los recursos estn
disponibles para los usuarios asegurndose de que estn ejecutndose en alguno de los nodos del clster.
El gestor de recursos de Heartbeat R1 (y muchos otros gestores de recursos en clster) ana diversos
recursos en grupos, llamados ResourceGroups. En ese caso, cada grupo es iniciado, detenido o movido en
su conjunto por el gestor de recursos del clster.
Instalacin de Heartbeat
Pasamos ahora a la instalacin y configuracin de la alta disponibilidad con Heartbeat. El primer paso
ser instalarlo en ambos nodos:
apt-get install heartbeat

Los ficheros de configuracin de Heartbeat estn en /etc/ha.d. Necesitamos crear tres ficheros:
ha.cf: fichero de configuracin principal.

haresources: fichero de configuracin de recursos.
authkeys: informacin de autenticacin.
Llegados a este punto, es preciso introducir dos nuevos conceptos de uso frecuente con Heartbeat,
direccin IP de servicio y direccin IP de administracin.
Una direccin de servicio es una direccin que es gestionada por el sistema de HA, y que es movida por
el clster all donde los servicios correspondientes se estn ejecutando. Estas direcciones de servicio son
direcciones a travs de las cuales los clientes y usuarios de los servicios en HA acceden a dichos
servicios. Tpicamente se almacenan en DNS con nombres conocidos.
Es importante que la direccin de servicio no sea gestionada por el sistema operativo, sino que sea el
software de HA el nico que la maneje. Si se le da una direccin administrativa al sistema de HA para que
la gestione, sto causar problemas pues se confundir al sistema de HA y el sistema operativo y el
sistema de HA se pelearn por el control de esta direccin.
El agente de recursos IPaddr2 es capaz de levantar una interfaz desde cero, incluso si no se ha
establecido ninguna direccin base (la versin anterior necesitaba de una direccin base en cualquier
interfaz, pues tan slo era capaz de aadir o eliminar direcciones a interfaces ya levantados). Adems, no
existe lmite en el nmero de direcciones IP por interfaz que IPaddr2 puede gestionar.
En cambio, una direccin administrativa es una direccin que est permanentemente asociada a un nodo
especfico del clster.
Tales direcciones son muy tiles, y se recomienda encarecidamente que una direccin de este tipo sea
reservada para cada nodo del clster, de manera que el administrador de sistemas pueda acceder al nodo
del clster incluso si no hay servicios ejecutndose. Para la mayora de sistemas, una direccin de este
tipo es obligatoria.
Asimismo, se recomienda que se reserve una de estas direcciones para cada interfaz, de modo que se
puedan testear las interfaces incluso cuando no estn activas.
Tal y como se ha especificado al inicio de este artculo, la configuracin de direcciones administrativas y

de servicio es la siguiente:
Direccin de servicio (inicialmente en pgsql1): 192.168.0.2

Direccin administrativa de pgsql1: 192.168.0.3
Direccin administrativa de pgsql2: 192.168.0.4
Si lo deseamos, para facilitar las pruebas o en vistas al futuro, podemos configurar la direccin de
servicio en el fichero /etc/network/interfaces siempre y cuando no incluyamos su autoconfiguracin (en
forma de directiva auto o allow-hotplug). El fichero /etc/network/interfaces del nodo pgsql1 podra
quedar tal y como sigue:
auto lo
iface lo inet loopback
# Direccin administrativa
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
# Direccin de servicio
iface eth0:0 inet static
address 192.168.0.2
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
De nuevo, ntese que la declaracin de la direccin de servicio en el fichero /etc/network/interfaces es

completamente prescindible al usar el agente de recursos IPaddr2. El nico propsito es dejar constancia
de ella en el sistema fuera de la configuracin de Heartbeat.
Configuracin de Heartbeat
Vamos ahora a editar los tres ficheros de configuracin de Heartbeat. Tomaremos los ficheros de ejemplo
de /usr/share/doc/heartbeat y los modificaremos a nuestro gusto. Empezaremos con el fichero ha.cf:
cd /etc/ha.d/
cp /usr/share/doc/heartbeat/ha.cf.gz /etc/ha.d/
gunzip ha.cf.gz
Editamos el fichero /etc/ha.d/ha.cf y lo configuramos a nuestro gusto, por ejemplo tal y como sigue:
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694
bcast eth0
auto_failback off
node pgsql1 # uname -n
node pgsql2 # uname -n
ping 192.168.0.1 # router
respawn hacluster /usr/lib/heartbeat/ipfail
Nos aseguramos, una vez ms, de que los nodos pgsql1 y pgsql2 existen en el fichero /etc/hosts de
ambos hosts pgsql1 y pgsql2:
127.0.0.1 localhost.localdomain localhost
192.168.0.1 router.dominio.com router
192.168.0.2 pgpool2.dominio.com pgpool2
Editamos el fichero /etc/ha.d/haresources y aadimos la siguiente lnea:
pgsql1 192.168.0.2 pgpool2
Esto indica a Heartbeat que el nodo maestro es pgsql1 y que debe gestionar dos recursos:
La direccin IP de servicio 192.168.0.2.

El servicio pgpool2.
El orden es muy importante. Primero se especifica el hostname del nodo que consideramos maestro.
Segundo, los recursos. El orden de los recursos tambin es crtico, pues Heartbeat los iniciar en orden
de izquierda a derecha, y los detendr en orden de derecha a izquierda (y no queremos que intente
arrancar el servicio pgpool2antes de disponer de la direccin IP en la cual pgpool-II debe escuchar).
Heartbeat buscar el script de arranque del servicio que debe gestionar en /etc/init.d y en
/etc/ha.d/resource.d. Siempre y cuando no creemos los enlaces en los directorios /etc/rcX.d, tanto da
que lo coloquemos en uno u otro, pues el sistema operativo no lo arrancar automticamente. Entonces,
creamos un enlace dbil al script de arranque pgpool2 para que Heartbeat pueda encontrarlo:
cd /etc/ha.d/resource.d
ln --symbolic /opt/pgpool2/etc/init.d/pgpool2
De este modo pgpool2 no se arrancar al iniciarse el nodo, sino que ser Heartbeat quien lo arranque si
detecta que as tiene que hacerlo, es decir, si decide que ste nodo debe asumir el papel de maestro.
A continuacin editamos el fichero /etc/ha.d/authkeys:
auth 1
1 sha1 57ef7ac02cf6aef7e13131622598f94778fb07d6
Para obtener la clave SHA1 de la contrasea en texto plano que querramos usar, utilizaremos el comando
sha1sum:
$ echo -n "<password>" | sha1sum
57ef7ac02cf6aef7e13131622598f94778fb07d6 -
Authkeys es obligatorio que sea accesible slo por el usuario root y que tenga permisos 600. Los dems,
664. Les damos los permisos adecuados a los ficheros:
chown root:root /etc/ha.d/authkeys /etc/ha.d/haresources /etc/ha.d/ha.cf
chmod 600 /etc/ha.d/authkeys
chmod 664 /etc/ha.d/haresources /etc/ha.d/ha.cf
Finalmente, configuraremos el logger daemon, especfico de Heartbeat. Tomamos el fichero de ejemplo

en /usr/share/doc/heartbeat:
cp --archive /usr/share/doc/heartbeat/logd.cf /etc/
Editamos el fichero /etc/logd.cf:
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility daemon
entity logd
useapphbd no
sendqlen 256
recvqlen 256
Repetiremos los anteriores pasos para el nodo pgsql2. Los ficheros de configuracin sern idnticos en
ambos nodos, sin diferencia alguna, por lo que podemos copiar los ficheros de configuracin desde pgsql1
a pgsql2 sin problemas.
Ahora ya estamos listos para iniciar la alta disponibilidad. Debido a que el logd puede estar iniciado con
una configuracin por defecto, vamos a asegurarnos primero de que Heartbeat est completamente
parado en ambos nodos:
/etc/init.d/heartbeat stop
Es posible que debamos esperar a algn timeout. Ahora, con una diferencia mxima de 120 segundos
(directiva initdead en /etc/ha.d/ha.cf), ejecutaremos el script de inicio, primero en pgsql1 y despus en
pgsql2:
/etc/init.d/heartbeat start
Podemos monitorizar el arranque de ambos Heartbeats a travs del fichero de log /var/log/ha-log. En el
nodo pgsql1 debera aparecernos la siguiente (o parecida) informacin en dicho log:
logd[4197]: info: logd started with /etc/logd.cf.
logd[4197]: WARN: Core dumps could be lost if multiple dumps occur.
logd[4197]: WARN: Consider setting non-default value in /proc/sys/kernel/core_pattern (or equivalent) for maximum supportability
logd[4197]: WARN: Consider setting /proc/sys/kernel/core_uses_pid (or equivalent) to 1 for maximum supportability
logd[4197]: info: G_main_add_SignalHandler: Added signal handler for signal 15
heartbeat[4272]: info: Enabling logging daemon
heartbeat[4272]: info: logfile and debug file are those specified in logd config file (default /etc/logd.cf)
heartbeat[4272]: WARN: Core dumps could be lost if multiple dumps occur.
heartbeat[4272]: WARN: Consider setting non-default value in /proc/sys/kernel/core_pattern (or equivalent) for maximum supportability
heartbeat[4272]: WARN: Consider setting /proc/sys/kernel/core_uses_pid (or equivalent) to 1 for maximum supportability
heartbeat[4272]: info: Version 2 support: false
heartbeat[4272]: WARN: logd is enabled but logfile/debugfile/logfacility is still configured in ha.cf
heartbeat[4272]: info: **************************
heartbeat[4272]: info: Configuration validated. Starting heartbeat 2.1.3
heartbeat[4273]: info: heartbeat: version 2.1.3
heartbeat[4273]: info: Heartbeat generation: 1225899638
heartbeat[4273]: info: glib: UDP Broadcast heartbeat started on port 694 (694) interface eth0
heartbeat[4273]: info: glib: UDP Broadcast heartbeat closed on port 694 interface eth0 - Status: 1
heartbeat[4273]: info: glib: ping heartbeat started.
heartbeat[4273]: info: G_main_add_TriggerHandler: Added signal manual handler
heartbeat[4273]: info: G_main_add_SignalHandler: Added signal handler for signal 17
heartbeat[4273]: info: Local status now set to: 'up'
heartbeat[4273]: info: Link 192.168.0.1:192.168.0.1 up.
heartbeat[4273]: info: Status update for node 192.168.0.1: status ping
heartbeat[4273]: info: Link pgsql1:eth0 up.
heartbeat[4273]: info: Status update for node pgsql2: status up
harc[4283][4289]: info: Running /etc/ha.d/rc.d/status status
heartbeat[4273]: info: Comm_now_up(): updating status to active
heartbeat[4273]: info: Local status now set to: 'active'
heartbeat[4273]: info: Starting child client "/usr/lib/heartbeat/ipfail" (107,111)
heartbeat[4273]: info: Starting "/usr/lib/heartbeat/ipfail" as uid 107 gid 111 (pid 4294)
heartbeat[4273]: info: Status update for node pgsql2: status active
ipfail[4294]: info: Status update: Node pgsql2 now has status active
ipfail[4294]: info: Asking other side for ping node count.
heartbeat[4273]: info: remote resource transition completed.
heartbeat[4273]: info: Initial resource acquisition complete (T_RESOURCES(us))
IPaddr[4346][4374]: INFO: Resource is stopped

heartbeat[4311]: info: Local Resource acquisition completed.
harc[4378][4383]: info: Running /etc/ha.d/rc.d/ip-request-resp ip-request-resp
ip-request-resp[4378][4388]: received ip-request-resp 192.168.0.2 OK yes
ResourceManager[4389][4399]: info: Acquiring resource group: pgsql1 192.168.0.2 pgpool2
IPaddr[4411][4439]: INFO: Resource is stopped
ResourceManager[4389][4455]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.2 start
IPaddr[4472][4502]: INFO: Using calculated nic for 192.168.0.2: eth0
IPaddr[4472][4507]: INFO: Using calculated netmask for 192.168.0.2: 255.255.255.0
IPaddr[4472][4529]: INFO: eval ifconfig eth0:0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255
IPaddr[4457][4548]: INFO: Success
ResourceManager[4389][4574]: info: Running /etc/ha.d/resource.d/pgpool2 start
ipfail[4294]: info: No giveup timer to abort.
En el nodo pgsql2 veremos informacin similar a la que sigue en el fichero de log:
logd[3793]: info: logd started with /etc/logd.cf.
logd[3793]: WARN: Core dumps could be lost if multiple dumps occur.
logd[3793]: WARN: Consider setting non-default value in /proc/sys/kernel/core_pattern (or equivalent) for maximum supportability
logd[3793]: WARN: Consider setting /proc/sys/kernel/core_uses_pid (or equivalent) to 1 for maximum supportability
heartbeat[3868]: info: Enabling logging daemon
heartbeat[3868]: info: logfile and debug file are those specified in logd config file (default /etc/logd.cf)
heartbeat[3868]: WARN: Core dumps could be lost if multiple dumps occur.
heartbeat[3868]: WARN: Consider setting non-default value in /proc/sys/kernel/core_pattern (or equivalent) for maximum supportability
heartbeat[3868]: WARN: Consider setting /proc/sys/kernel/core_uses_pid (or equivalent) to 1 for maximum supportability
heartbeat[3868]: info: Version 2 support: false
heartbeat[3868]: WARN: logd is enabled but logfile/debugfile/logfacility is still configured in ha.cf
heartbeat[3868]: info: **************************
heartbeat[3868]: info: Configuration validated. Starting heartbeat 2.1.3
heartbeat[3869]: info: heartbeat: version 2.1.3
heartbeat[3869]: info: Heartbeat generation: 1225899699
heartbeat[3869]: info: glib: UDP Broadcast heartbeat started on port 694 (694) interface eth0
heartbeat[3869]: info: glib: UDP Broadcast heartbeat closed on port 694 interface eth0 - Status: 1
heartbeat[3869]: info: glib: ping heartbeat started.
heartbeat[3869]: info: G_main_add_SignalHandler: Added signal handler for signal 17
heartbeat[3869]: info: Local status now set to: 'up'
heartbeat[3869]: info: Link 192.168.0.1:192.168.0.1 up.
heartbeat[3869]: info: Status update for node 192.168.0.1: status ping
heartbeat[3869]: info: Status update for node pgsql1: status up
heartbeat[3869]: info: Status update for node pgsql1: status active
heartbeat[3869]: info: Comm_now_up(): updating status to active
heartbeat[3869]: info: Local status now set to: 'active'
heartbeat[3869]: info: Starting child client "/usr/lib/heartbeat/ipfail" (107,111)
heartbeat[3881]: info: Starting "/usr/lib/heartbeat/ipfail" as uid 107 gid 111 (pid 3881)
heartbeat[3869]: info: local resource transition completed.

heartbeat[3869]: info: Initial resource acquisition complete (T_RESOURCES(us))
heartbeat[3904]: info: No local resources [/usr/share/heartbeat/ResourceManager listkeys pgsql2] to acquire.
ipfail[3881]: info: Ping node count is balanced.
Podemos observar como Heartbeat se ha encargado de asociar la direccin IP 192.168.0.2 al primer alias
disponible de la interfaz eth0, es decir, eth0:0. Tambin podremos observar como pgpool-II est
levantado y es capaz de servir conexiones.
En el syslog podremos observar que ha establecido la conexin con ambos servidores de PostgreSQL y
est esperando peticiones:
$ tail -n 500 /var/log/syslog | grep pgpool | ccze -A
pgsql1 pgpool: LOG: pid 4594: pgpool successfully started
Simulacin de la cada del servicio
A continuacin vamos a simular la cada del nodo maestro, pgsql1. Si estamos trabajando con dos
mquinas, esto es tan sencillo como desconectar dicho nodo de la red. En el caso de este artculo, se us
Xen Hypervisor para crear las dos mquinas virtuales dentro de la misma mquina fsica, por lo que se
ejecut el siguiente comando (las mquinas virtuales se haban creado con las xen-tools de Steve Kemp):
xm destroy pgsql1
Al cabo de un mximo de 30 segundos, deberamos ver informacin parecida a la siguiente en el fichero

de log de Heartbeat del nodo pgsql2:
heartbeat[3869] WARN: node pgsql1: is dead
ipfail[3881] 2008/11/05_17:08:10 info: Status update: Node pgsql1 now has status dead
heartbeat[3869] WARN: No STONITH device configured.
heartbeat[3869] WARN: Shared disks are not protected.
heartbeat[3869] info: Resources being acquired from pgsql1.
heartbeat[3869] info: Link pgsql1:eth0 dead.
harc[3942][3954] info: Running /etc/ha.d/rc.d/status status
heartbeat[3943] info: No local resources [/usr/share/heartbeat/ResourceManager listkeys pgsql2] to acquire.
mach_down[3964][3984] info: Taking over resource group 192.168.0.2
ResourceManager[3985][3995] info: Acquiring resource group: pgsql1 192.168.0.2 pgpool2
IPaddr[4007][4035] INFO: Resource is stopped
ResourceManager[3985][4051] info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.2 start
IPaddr[4068][4098] INFO: Using calculated nic for 192.168.0.2: eth0
IPaddr[4068][4103] INFO: Using calculated netmask for 192.168.0.2: 255.255.255.0
IPaddr[4068][4125] INFO: eval ifconfig eth0:0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255
IPaddr[4053][4144] INFO: Success
ResourceManager[3985][4172] info: Running /etc/ha.d/resource.d/pgpool2 start
mach_down[3964][4199] info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
mach_down[3964][4203] info: mach_down takeover complete for node pgsql1.
heartbeat[3869] info: mach_down takeover complete.
ipfail[3881] info: NS: We are still alive!
ipfail[3881] info: Link Status update: Link pgsql1/eth0 now has status dead
ipfail[3881] info: Asking other side for ping node count.
ipfail[3881] info: Checking remote count of ping nodes.
Vemos como ahora el nodo pgsql2 tiene la direccin IP 192.168.0.2 (podemos verificarlo con el comando
ifconfig) y como pgpool-II est arrancado (podemos verificarlo con el comando ps xua |grep ^postgres).
Asimismo, podemos observar como pgpool-II ha realizado un health check nada ms iniciarse y, al ver
que el servidor de PostgreSQL del nodo 192.168.0.3 no estaba disponible, ha realizado la pertinente
degeneracin de ese nodo (que, recordemos, a efectos del nuevo pgpool-II, es un nodo secundario):
$ tail -n 500 /var/log/syslog | grep pgpool | ccze -A
pgsql2 pgpool: LOG: pid 4195: pgpool successfully started
pgsql2 pgpool: ERROR: pid 4195: connect_inet_domain_socket: connect() failed: No route to host
pgsql2 pgpool: ERROR: pid 4195: health check failed. 1 th host 192.168.0.3 at port 5432 is down
pgsql2 pgpool: LOG: pid 4195: set 1 th backend down status
pgsql2 pgpool: LOG: pid 4195: starting degeneration. shutdown host 192.168.0.3(5432)
pgsql2 pgpool: LOG: pid 4195: failover_handler: do not restart pgpool. same master node 0 was selected
pgsql2 pgpool: LOG: pid 4195: failover done. shutdown host 192.168.0.3(5432)
pgsql2 pgpool: LOG: pid 4195: execute command: /var/lib/postgresql/8.3/main/pgpool-failover 1 192.168.0.3 5432
/var/lib/postgresql/8.3/main 0 0
pgsql2 pgpool[4243]: Executing pgpool-failover as user postgres
pgsql2 pgpool: /var/lib/postgresql/8.3/main/pgpool-failover: 15: Failover of node 1 at hostname 192.168.0.3. New master node is 0. Old
master node was 0.: not found
Ntese que, a raz de la instalacin de Heartbeat, pgpool-II est ahora escuchando en la IP 192.168.0.2,
por lo cual hay que mandar al puerto 9898 de esa IP los comandos de PCP. La ventaja es que siempre
lanzaremos nuestros comandos PCP contra esa direccin IP, pues Heartbeat se encargar de llevarla de
un nodo a otro segn sea necesario. Adems, las peticiones de pgpool-II a PostgreSQL vienen ahora
desde esa direccin IP, por lo que es conveniente revisar que nuestros ficheros
/etc/postgresql/8.3/main/pg_hba.conf permiten las conexiones desde ambas con el usuario pgpool2.
Por otra parte, los comandos que nuestros clientes quieran mandar contra el clster usarn, a partir de
ahora, la direccin IP 192.168.0.2 y el puerto 9999. Al igual que antes, dado que Heartbeat se encargar
de mover esta direccin IP y el servicio pgpool2 de nodo a nodo, nuestros clientes siempre funcionarn
de la misma manera. Este es uno de los propsitos principales de la alta disponibilidad que acabamos de
configurar (adems de la alta disponibilidad de la que gozamos, por supuesto).
Podemos probar nuestro clster con un simple comando como el que sigue:
psql -h 192.168.0.2 -p 9999 -U pgpool2 -d bench_replication -c "UPDATE ACCOUNTS SET abalance = 1009 WHERE aid = 10"
Herramientas de monitorizacin
En Internet pueden encontrarse un gran nmero de herramientas de gestin y monitorizacin de
PostgreSQL, tanto de cdigo abierto como propietarias. A continuacin se presenta una lista de algunas
de ellas que, personalmente, me resultan de gran utilidad.
pg_osmem y pg_buffercache
pg_osmem es un script hecho en Python por Kenny Gorman que permite obtener informacin sobre la
memoria cach que un sistema Linux est dedicando al servidor PostgreSQL. Utiliza un script en Perl
llamado fincore (pronunciado en ingls eff in core), creado por David Plonka, Archit Gupta y Dale Carder
de la universidad de Wisconsin-Madison y que fue presentado en la LISA '07.
Su instalacin y uso son muy sencillos:
Crear el directorio /root/bin y cambiarse a l.

Descargar fincore desde http://net.doit.wisc.edu/~plonka/fincore/fincore
Crear el fichero /root/pg_osmem/pg_osmem a partir del script que hay en la pgina web de
Kenny Gorman.
Crear el directorio /root/pg_osmem/data.
Instalar la dependencia psycopg2 (paquete python-psycopg2 en Debian).
Instalar la dependiencia inline (paquete libinline-perl en Debian).
Modificar el script /root/pg_osmem/pg_osmem para adecuarlo a nuestro sistema:
Cambiar /home/postgres/python/bin/python por /usr/bin/python.
Cambiar la variable fincore por /root/bin/fincore.
Cambiar la variable mydir por /var/lib/postgresql/8.3/main/base.
Ejecutar con la siguiente sentencia (suponemos que /root/bin est en el PATH del usuario root):
pg_osmem --username=pgpool2 --password='' --machine=pgsql1 --dbname=bench_replication
El fichero de configuracin /etc/postgresql/8.3/main/pg_hba.conf deber estar configurado

adecuadamente.
pg_buffercache es un mdulo de PostgreSQL, habitualmente hallado en el paquete postgresql-contrib-

8.3, que proporciona maneras de examinar lo que est ocurriendo en la cache de memoria compartida de
PostgreSQL en tiempo real (no a nivel de sistema operativo, pues para eso necesitamos pg_osmem). Su
instalacin es muy sencilla:
$ psql -d bench_replication < /usr/share/postgresql/8.3/contrib/pg_buffercache.sql
SET
CREATE FUNCTION
CREATE VIEW
REVOKE
REVOKE
Entonces, mediante el script pg_osmem podemos obtener una salida similar a la siguiente:
$ pg_osmem --username=pgpool2 --password='' --machine=pgsql1 --dbname=bench_replication
OS Cache Usage:
bench_replication:accounts_pkey:566272
bench_replication:pg_proc:102400
bench_replication:pg_proc_proname_args_nsp_index:79872
bench_replication:pg_depend:79872
bench_replication:pg_depend_reference_index:65536
[..]
Luego, gracias al mdulo pg_buffercache, podemos lanzar la siguiente consulta SQL:
psql -d bench_replication
# SELECT current_database(),c.relname, count(*)*8192 as bytes
FROM pg_buffercache b INNER JOIN pg_class c
ON b.relfilenode = c.relfilenode
AND b.reldatabase IN (0, (
SELECT oid FROM pg_database
WHERE datname = current_database()))
GROUP BY c.relname
ORDER BY 3 DESC LIMIT 25;
current_database | relname | bytes
-------------------+---------------+----------
bench_replication | accounts | 13434880
bench_replication | accounts_pkey | 262144
bench_replication | pg_attribute | 155648
bench_replication | pg_statistic | 122880
bench_replication | pg_operator | 106496

[..]
(25 rows)
Gracias a estos dos cdigos, podemos ver el conjunto de buffers ms utilizado en la cach del sistema
operativo y compararlo con la cach de PostgreSQL. La salida de ambos comandos es en bytes.
pg_top
pg_top es un top para PostgreSQL, derivado del top de UNIX. Similar a top, pg_top permite monitorizar
los procesos de PostgreSQL y, adems, ofrece estas otras funcionalidades:
Ver las consultas SQL que est ejecutando un proceso.

Ver el query plan de una consulta SQL que se est ejecutando.
Ver los bloqueos realizados por un proceso.
Ver la estadstica de las tablas.
Ver la estadstica de los ndices.
Los fuentes de pg_top pueden descargarse de su pgina web en PgFoundry. Tambin podemos bajarnos
la ltima versin de desarrollo del repositorio Git de pgFoundry mediante el siguiente comando:
cd /usr/local/src
git clone git://git.postgresql.org/git/pg_top.git
cd pg_top
./autogen.sh
Podemos instalar Git mediante el siguiente comando:
apt-get install git-cvs
Instalaremos las dependencias de compilacin con el siguiente comando:
apt-get install libncurses5-dev
Los paquetes build-essential, linux-headers-server, libpq-dev, libpq5 y postgresql-server-dev-8.3 ya los

habamos instalado durante la instalacin de pgpool-II y de PostgreSQL.
pg_top se instala por defecto en /usr/local/bin, pero podemos cambiar la ruta mediante el parmetro
--prefix del script configure:
cd /usr/local/src
wget http://pgfoundry.org/frs/download.php/1780/pg_top-3.6.2.tar.bz2
tar -xjf pg_top-3.6.2.tar.bz2
cd pg_top-3.6.2
./configure --prefix=/opt/pg_top
make
make install
El uso de pg_top es anlogo al de top. Tan slo hay que invocar el ejecutable y usar las teclas para
obtener diferentes vistas e informacin de los procesos deseados. El ejecutable requiere tres parmetros:
La base de datos (parmetro -d).

El usuario (parmetro -U).
La contrasea, si es necesaria (parmetro -W).
Entonces, la ejecucin de pg_top sera tal y como sigue:
/opt/pg_top/bin/pg_top -U pgpool2 -d bench_replication
pg_top asume localhost como hostname y 5432 como puerto por defecto. Usa el usuario de sistema
como medio de autenticacin por defecto, por lo cual deberemos pasarle datos de usuario y contrasea o
ejecutarlo como usuario postgres, dependiendo de la configuracin que tengamos en
/etc/postgresql/8.3/main/pg_hba.conf.
Podemos crearnos un script /opt/pg_top/pg_top donde hacer la llamada completa con todos los datos y
hacernos el trabajo ms sencillo, por ejemplo:
#!/bin/bash
/usr/bin/sudo /bin/su - postgres -c '/opt/pg_top/bin/pg_top'
Y luego aadir la ruta al PATH del sistema en /etc/profile.
ps
ps, o process status, la famosa utilidad presente en todos los UNIX, es una til herramienta para tener
una primera impresin de qu est haciendo PostgreSQL. Un sencillo comando tal que el que sigue ser
suficiente:
$ ps auxww | grep ^postgres
postgres 960 0.0 1.1 6104 1480 pts/1 SN 13:17 0:00 postgres -i
postgres 963 0.0 1.1 7084 1472 pts/1 SN 13:17 0:00 postgres: writer process
postgres 965 0.0 1.1 6152 1512 pts/1 SN 13:17 0:00 postgres: stats collector process
postgres 998 0.0 2.3 6532 2992 pts/1 SN 13:18 0:00 postgres: tgl runbug 127.0.0.1 idle
postgres 1003 0.0 2.4 6532 3128 pts/1 SN 13:19 0:00 postgres: tgl regression [local] SELECT waiting
postgres 1016 0.1 2.4 6532 3080 pts/1 SN 13:19 0:00 postgres: tgl regression [local] idle in transaction
pgd
pgstat, otra utilidad desarrollada por Kenny Gorman, es muy similar a iostat pero orientada a bases de
datos. Es una utilidad muy til para realizar diagnsticos rpidos, tests de rendimiento, etc. La salida es
adecuada para ser importada en hojas de clculo o en programas que puedan generar grficas.
En la pgina web de Kenny Gorman se explica cmo obtener grficas de la salida de pgd usando gnuplot.
Ver la bibliografa para el enlace.
La instalacin de pgd es muy sencilla:
Descargar pgstat desde pgFoundry.

Descomprimirlo en /root/bin o donde consideremos oportuno.
Editar el fichero y cambiar los valores por defecto de los parmetros en la lnea 16. De esta forma
podremos llegar a no tener que especificar ningn parmetro o, como mximo, la base de datos.
La utilidad la llamaremos con un sencillo pgstat -d bench_replication.
iotop
Iotop es un script de Python con una interfaz de usuario similar a la de top que sirve para mostrar qu
proceso est originando qu carga de lecturas y escrituras de disco (E/S). Requiere Python 2.5 o superior
y un kernel de Linux versin 2.6.20 o superior. Este script muestra la misma informacin que el comando
vmstat, pero asociando la carga al proceso que la genera y mostrando la informacin de una forma
mucho ms til para el administrador de sistemas.
Su instalacin es muy sencilla pues, a partir de Lenny, viene como paquete Debian:
apt-get install iotop python-pkg-resources
Optimizacin de PostgreSQL
Para un sistema inicial de pruebas, tanto pgsql1 como pgsql2 tienen 1 GB de memoria RAM. Teniendo en
cuenta esta situacin, se configurarn los siguientes parmetros en el fichero de configuracin de
PostgreSQL /etc/postgresql/8.3/main/postgresql.conf:
max_connections = 100
shared_buffers = 256MB
work_mem = 2MB
effective_cache_size = 512MB
Work Memory es por conexin, por lo que hay que calcular un mximo de 2 * 100 = 200 MB para el total
de conexiones. Effective Cache Size debera ser entre el 50 y el 75% de la memoria RAM fsica,
dependiendo de si hay otros servicios ejecutndose en la mquina o no.
Respecto del kernel, para poder reservar 512 MB de shared buffers necesitaremos un tamao mximo de
un segmento compartido igual al valor que nos devuelva el error de PostgreSQL al arrancar, 279.134.208
bytes, unos 266 MB.
La variable SHMMAX del kernel indica el tamao mximo de los segmentos de memoria compartida, y
debe ser de, al menos, varios megabytes. La variable de kernel SHMALL indica el nmero total de pginas
de memoria compartida disponibles. SHMALL es igual a SHMMAX dividido por PAGE_SIZE, redondeado
hacia arriba. PAGE_SIZE es, por defecto, de 4 kilobytes.
Ejecutaremos los siguientes comandos en la consola para alterar los valores:
sysctl -w kernel.shmmax=279134208
sysctl -w kernel.shmall=2097152
El primero son bytes, el segundo pginas. Para asegurarnos que los valores permanezcan tras un reinicio,
aadiremos las siguientes dos lneas al fichero /etc/sysctl.conf:
kernel.shmmax=556212224
kernel.shmall=2097152
El valor actual de estos parmetros se puede obtener con:
cat /proc/sys/kernel/shmmax
cat /proc/sys/kernel/shmall
El valor por defecto de SHMMAX suele ser 33.554.432 bytes. El valor por defecto del nmero de pginas
que un segmento compartido puede tener ya es mayor que lo que necesitamos (553.607.168 / 4096 =
135.158 < 2.097.152), as es que no har falta modificarlo ni aadir la lnea correspondiente a
/etc/sysctl.conf.
Autovacuum y cargas de datos
PostgreSQL 8.3 realiza un vacuum automtico de manera peridica, por lo que no debera de ser
necesario ejecutar un FULL VACUUM a menos que grandes porciones (ms de un tercio o, incluso, ms de
la mitad) de las tablas de borren e inserten con frecuencia (por ejemplo durante cargas de datos
nocturnas mediante procesos por lotes). En este caso, ejecutar VACUUM ANALIZE para que la
informacin estadstica del planificador de consultas est actualizada es tambin muy conveniente. En la
documentacin oficial de PostgreSQL (ver bibliografa) podemos encontrar varios consejos muy tiles en
el caso de realizar grandes cargas de datos (iniciales o peridicas).
Procesos errantes
En el caso de detectar un proceso en segundo plano que lleve ocupado "demasiado" tiempo, podemos
determinar qu est intentando llevar a cabo dicho thread, a partir de su PID, mediane la siguiente
consulta:
SELECT * FROM pg_stat_activity WHERE procpid = <pid>

Administracion de Postgres

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Administracion de Postgres

Caricato da

Copyright:

Formati disponibili

Temas a buscar

PostgreSQL es un Sistema de gestin de bases de datos relacional orientado a objetos y libre,

Como muchos otros proyectos de cdigo abierto, el desarrollo de PostgreSQL no es

1Nombre del producto

Nombre del producto

Para el ao 1996 se unieron al proyecto personas ajenas a la Universidad como Marc

En el ao 1996 decidieron cambiar el nombre de Postgres95 de tal modo que refleje la

En 2001, Command Prompt, Inc. lanz Mammonth PostgreSQL, la ms antigua

A mediados de 2005 otras dos compaas anunciaron planes para comercializar

En octubre de 2005, John Loiacono, vicepresidente ejecutivo de software en Sun

En agosto de 2007 EnterpriseDB anunci el Postgres Resource Center y EnterpriseDB

El proyecto PostgreSQL contina haciendo lanzamientos principales anualmente y

Amplia variedad de tipos nativos

PostgreSQL provee nativamente soporte para:

Nmeros de precisin arbitraria.

Bloques de cdigo que se ejecutan en el servidor. Pueden ser escritos en varios

Algunos de los lenguajes que se pueden usar son los siguientes:

Un lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).

-Seguridad en trminos generales

-Integridad en BD: restricciones en el dominio

Productos alrededor de PostgreSQL

Full text search

1999 LinuxWorld Editor's Choice Award for Best Database

pgAdmin III es una aplicacin grfica para gestionar PostgreSQL

La versin 1.4.3 trae importantes mejoras

Actualizar a una versin ms moderna

Cambia gutsy por feisty o dapper segn sea el caso.

2.- Aade el siguiente repositorio de fuentes (la puedes eliminar al final):

4.- Instalamos lo necesario para compilar:

5.- Instalamos las dependencias necesarias para compilar el paquete:

7.- Instala los paquetes generados:

8.- Eliminamos los ficheros intermedios

Administracin y manual de PostgreSQL en Linux

Instalacin de PostgreSQL en CentOS

yum install postgresql-server postgresql

El servicio no queda activado en el arranque, as que lo activaremos con la utilidad chkconfig:

Iniciando la base de datos: [ OK ]

Iniciando servicios postgresql: [ OK ]

Conexin a un servidor PostgreSQL

Para conectarnos al servidor PostgreSQL nos cambiamos al usuario postgres y utilizamos el

$ psql -d template1 -U postgres

Type: \copyright for distribution terms

\h for help with SQL commands

\? for help with psql commands

\g or terminate with semicolon to execute query

Permitir conexiones remotas a PostgreSQL

# netstat -punta | grep LISTEN

tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN

Para modificar este comportamiento tenemos que editar el fichero

host all all 192.168.0.0/24 trust

host all all 10.10.0.1/32 trust

Adems, tenemos que editar el fichero /var/lib/pgsql/data/postgresql.conf y modificar el

Parando el servicio postgresql: [ OK ]

Iniciando servicios postgresql: [ OK ]

# netstat -punta | grep LISTEN

tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN

En este ejemplo, permitimos el acceso a la red 192.168.0.0/24 y a la IP 10.10.0.1, quedando

Modificar la contrasea del usuario postgres de PostgreSQL

$ psql -d template1 -U postgres

template1=# ALTER USER postgres WITH PASSWORD 'zaQ6RzRhFb';

template1=# SELECT VERSION();

Backup y restore de bases de datos en PostgreSQL

En PostgreSQL tenemos el comando pg_dump para realizar copias de seguridad de BBDD, su

Name | Owner | Encoding