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 */ }; |
/* file trace.c */ static char *opt_names[] = { ... "foo", /* trace foo functions */ "fooparam" /* foo tunable parameter */ }; |
/* 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:
No tenemos que definir un switch diferente para cada idea que queramos controlar. Todas las opciones est�n definidas como palabras claves en un fichero externo almacenado en el directorio de datos.
No tenemos que rearrancar Postgres para cambiar el valor de alguna opci�n. Normalmente las opciones del servidor se especifican al postmaster y pasados a cada servidor cuando sea arrancado. Ahora son leidos de un fichero.
Podemos cambiar las opciones sobre la marcha mientras el servidor est� corriendo. Podemos de este modo investigar algunos problemas activando los mensajes de seguimiento s�lo cuando aparece el problema. Podemos tambi�n intentar diferentes valores de par�metros ajustables.
# comment option=integer_value # set value for option option # set option = 1 option+ # set option = 1 option- # set option = 0 |
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.