pg_options

Nota

Aportado por Massimo Dal Zotto

El fichero opcional data/pg_options contiene opciones de tiempo de ejecuci�n utilizadas por el servidor para controlar los mensajes de seguimiento y otros par�metros ajustables de servidor. Lo que hace a este fichero interesante es el hecho de que es re-leido por un servidor qeu recibe una se�al SIGHUP, haciendo as� posible cambiar opciones de tiempo de ejecuci�n sobre la marcha sin necesidad de rearrancar Postgres. Las opciones especificadas en este fichero pueden ser banderas de debugging utilizadas por el paquete de seguimiento (backend/utils/misc/trace.c) o par�metros num�ricos que pueden ser usados por el servidor para controlar su comportamiento. Las nuevas opciones y par�metros deben ser definidos en backend/utils/misc/trace.c y backend/include/utils/trace.h.

Por ejemplo, supongamos que queremos a�adir mensajes de seguimiento condicional y un par�metro num�rico ajustable al c�digo en el fichero foo.c. Todo lo que necesitamos hacer es a�adir la constante TRACE_FOO y OPT_FOO_PARAM en backend/include/utils/trace.h:

/* file trace.h */
enum pg_option_enum {
    ...
    TRACE_FOO,			/* trace foo functions */
    OPT_FOO_PARAM,		/* foo tunable parameter */

    NUM_PG_OPTIONS              /* must be the last item of enum */
};
   
y una l�nea correspondiente en backend/utils/misc/trace.c:
/* file trace.c */
static char *opt_names[] = {
    ...
    "foo",            		/* trace foo functions */
    "fooparam"         		/* foo tunable parameter */
};
   
Las opciones se deben especificar en los dos ficheros ex�ctamente en el mismo orden. En los ficheros fuente foo podemos ahora hacer referencia a las nuevas banderas con:
/* file foo.c */
#include "trace.h"
#define foo_param pg_options[OPT_FOO_PARAM]

int
foo_function(int x, int y)
{
    TPRINTF(TRACE_FOO, "entering foo_function, foo_param=%d", foo_param);
    if (foo_param > 10) {
        do_more_foo(x, y);
    }
}
   

Los ficheros existentes que utilizan banderas de seguimiento privadas pueden cambiarse simplemente a�adiendo el siguiente c�digo:

#include "trace.h"
/* int my_own_flag = 0; -- removed */
#define my_own_flag pg_options[OPT_MY_OWN_FLAG]
   

Todas las pg_options son inicializadas a cero en el arranque del servidor. Si necesitamos un valor de defecto diferente necesitaremos a�adir alg�n c�digo de inicializaci�n en el principio de PostgresMain. Ahora podemos fijar el par�metro foo_param y activar el seguimiento foo escribiendo valores en el fichero data/pg_options:

# file pg_options
....
foo=1
fooparam=17
   

Las nuevas opciones ser�n leidas por todos los nuevos servidores conforme van arrancando. Para hacer efectivos los cambios para todos los servidores que est�n en funcionamiento, necesitaremos enviar un SIGHUP al postmaster. La se�al ser� enviada autom�ticamente a todos los servidores. Podemos activar los cambios tambi�n para un servidor espec�fico individual enviandole la se�al SIGHUP directamente a �l.

Las pg_options pueden tambi�n especificarse con el interruptor (switch) -T de Postgres:

postgres options -T "verbose=2,query,hostlookup-"
   

Las funciones utilizadas para imprimir los errores y los mensajes de debug pueden hacer uso ahora de la facilidad sislog(2). Los mensajes impresos en stdout y stderr son preformatados con una marca horaria que contiene tambi�n la identificaci�n del proceso del servidor:

#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 incrementa tambi�n la capacidad de leer los ficheros de mensajes y permite a las personas el conocimiento exacto de lo que cada servidor est� haciendo y en qu� momento. Tambi�n hace m�s f�cil escribir programas con awk o perl que revisen el rastro para detectar errores o problemas en la base de datos, o calcular estadisticas de tiempo de las transacciones.

Los mensajes impresos en el syslog utilizan la facilidad de rastro LOG_LOCAL0. El uso de syslog puede ser controlada con la pg_option syslog. Desgraciadamente, muchas funciones llaman directamente a printf() para imprimir sus mensajes en stdout o stderr y su salida no puede ser redirigida a syslog o tener indicaciones cronol�gicas en ella. Ser�a deseable que todas las llamadas a printf fueran reemplazadas con la macro PRINTF y la salida a stderr fuese cambiada para utilizar EPRINTF en su lugar, de modo que podamos controlar todas las salidas de un modo uniforme.

El nuevo mecanismo de las pg_options es m�s conveniente que definir nuevas opciones de switch en los servidores porque:

El formato de las pg_options es como sigue:
# comment
option=integer_value  # set value for option
option                # set option = 1
option+               # set option = 1
option-               # set option = 0
   
Notese que keyword puede tambi�n ser una abreviatura del nombre de opci�n definida en backend/utils/misc/trace.c.

Refierase al cap�tulo de la Gu�a del Administrador sobre las opciones de tiempo de ejecuci�n para una lista completa de opciones soportadas actualmente.

Algo del c�digo existente que utiliza variables privadas e interruptores de opciones se han cambiado para hacer uso de las posibilidades de las pg_options, fundamentalmente en postgres.c. Ser�a deseable modificar todo el codigo existente en este sentido, de modo que podamos hacer uso de muchos de los switches en la l�nea de comando de Postgres y poder tener m�s opciones ajustables con un lugar �nico para situar los valores de las opciones.