Configuración de Postgresql: bytea_output

19.11.1. Comportamiento de declaración

19.11.2. Configuración regional y formato

19.11.3. Precarga de biblioteca compartida

19.11.4. Otros valores predeterminados

19.11.1. Comportamiento de declaración

client_min_messages (enum)

Controla qué niveles de mensajes se envían al cliente. Los valores válidos son DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, y ERROR. Cada nivel incluye todos los niveles que le siguen. Cuanto más tarde el nivel, se envían menos mensajes. El valor predeterminado es NOTICE. Tenga en cuenta que LOG tiene un rango diferente aquí que en log_min_messages.

INFO Los mensajes de nivel siempre se envían al cliente.

search_path (string)

Esta variable especifica el orden en el que se buscan los esquemas cuando se hace referencia a un objeto (tabla, tipo de datos, función, etc.) mediante un nombre simple sin esquema especificado. Cuando hay objetos de nombres idénticos en diferentes esquemas, se utiliza el que se encuentra primero en la ruta de búsqueda. Un objeto que no está en ninguno de los esquemas en la ruta de búsqueda solo puede ser referenciado especificando su esquema contenedor con un nombre calificado (con puntos).

El valor de search_path debe ser una lista de nombres de esquema separados por comas. Cualquier nombre que no sea un esquema existente o que sea un esquema para el que el usuario no tenga USAGE permiso, se ignora en silencio.

Si uno de los elementos de la lista es el nombre especial $user, luego el esquema que tiene el nombre devuelto por CURRENT_USER se sustituye, si existe tal esquema y el usuario ha USAGE permiso para ello. (Que no, $user se ignora.)

El esquema del catálogo del sistema, pg_catalog, siempre se busca, ya sea que se mencione en la ruta o no. Si se menciona en la ruta, se buscará en el orden especificado. Si pg_catalog no está en el camino, entonces se buscará antes de buscando cualquiera de los elementos de la ruta.

Asimismo, el esquema de tabla temporal de la sesión actual, pg_temp_nnn, siempre se busca si existe. Se puede enumerar explícitamente en la ruta utilizando el alias pg_temp. Si no aparece en la ruta, primero se busca (incluso antes pg_catalog). Sin embargo, el esquema temporal solo se busca por relación (tabla, vista, secuencia, etc.) y nombres de tipo de datos. Nunca se buscan nombres de funciones o operadores.

Cuando los objetos se crean sin especificar un esquema de destino en particular, se colocarán en el primer esquema válido nombrado en search_path. Se informa de un error si la ruta de búsqueda está vacía.

El valor predeterminado para este parámetro es "$user", public. Esta configuración admite el uso compartido de una base de datos (donde ningún usuario tiene esquemas privados y todos comparten el uso de public), esquemas privados por usuario y combinaciones de estos. Se pueden obtener otros efectos modificando la configuración de la ruta de búsqueda predeterminada, ya sea globalmente o por usuario.

Para obtener más información sobre el manejo de esquemas, consulte la Sección 5.9. En particular, la configuración predeterminada es adecuada solo cuando la base de datos tiene un solo usuario o unos pocos usuarios que confían mutuamente.

El valor efectivo actual de la ruta de búsqueda se puede examinar a través de la función SQL current_schemas (consulte la Sección 9.26). Esto no es exactamente lo mismo que examinar el valor de search_path, ya que current_schemas muestra cómo aparecen los elementos en search_path fueron resueltos.

row_security (boolean)

Esta variable controla si generar un error en lugar de aplicar una política de seguridad de fila. Cuando se establece en on, las políticas se aplican normalmente. Cuando se establece en off, las consultas fallan, que de otro modo aplicarían al menos una política. El valor predeterminado es on. Cambiar a off donde la visibilidad limitada de la fila podría causar resultados incorrectos; por ejemplo, pg_dump realiza ese cambio de forma predeterminada. Esta variable no tiene ningún efecto en los roles que omiten la política de seguridad de cada fila, es decir, los superusuarios y los roles con el BYPASSRLS atributo.

Para obtener más información sobre las políticas de seguridad de filas, consulte CREAR POLÍTICA.

default_table_access_method (string)

Este parámetro especifica el método de acceso a la tabla predeterminado que se utilizará al crear tablas o vistas materializadas si el CREATE comando no especifica explícitamente un método de acceso, o cuando SELECT ... INTO se utiliza, lo que no permite especificar un método de acceso a la tabla. El valor predeterminado es heap.

default_tablespace (string)

Esta variable especifica el espacio de tabla predeterminado en el que crear objetos (tablas e índices) cuando un CREATE El comando no especifica explícitamente un espacio de tabla. También determina el espacio de tabla al que una relación particionada dirigirá las particiones futuras.

El valor es el nombre de un espacio de tabla o una cadena vacía para especificar usando el espacio de tabla predeterminado de la base de datos actual. Si el valor no coincide con el nombre de ningún espacio de tabla existente, PostgreSQL utilizará automáticamente el espacio de tabla predeterminado de la base de datos actual. Si se especifica un espacio de tabla no predeterminado, el usuario debe tener CREATE privilegio para ello, o los intentos de creación fallarán.

Esta variable no se usa para tablas temporales; para ellos, en su lugar, se consulta temp_tablespaces.

Esta variable tampoco se utiliza al crear bases de datos. De forma predeterminada, una nueva base de datos hereda su configuración de espacio de tabla de la base de datos de plantilla de la que se copia.

Para obtener más información sobre los espacios de tabla, consulte la Sección 22.6.

temp_tablespaces (string)

Esta variable especifica espacios de tabla en los que crear objetos temporales (tablas temporales e índices en tablas temporales) cuando un CREATE El comando no especifica explícitamente un espacio de tabla. En estos espacios de tabla también se crean archivos temporales para propósitos tales como ordenar grandes conjuntos de datos.

El valor es una lista de nombres de espacios de tabla. Cuando hay más de un nombre en la lista, PostgreSQL elige un miembro aleatorio de la lista cada vez que se crea un objeto temporal; excepto que dentro de una transacción, los objetos temporales creados sucesivamente se colocan en sucesivos espacios de tabla de la lista. Si el elemento seleccionado de la lista es una cadena vacía, PostgreSQL utilizará automáticamente el espacio de tabla predeterminado de la base de datos actual.

Cuando temp_tablespaces se establece de forma interactiva, especificar un espacio de tabla inexistente es un error, al igual que especificar un espacio de tabla para el que el usuario no tiene CREATE privilegio. Sin embargo, cuando se usa un valor establecido previamente, los espacios de tabla inexistentes se ignoran, al igual que los espacios de tabla para los que el usuario carece CREATE privilegio. En particular, esta regla se aplica cuando se usa un valor establecido en postgresql.conf.

El valor predeterminado es una cadena vacía, lo que da como resultado que todos los objetos temporales se creen en el espacio de tabla predeterminado de la base de datos actual.

Consulte también default_tablespace.

check_function_bodies (boolean)

Este parámetro normalmente está activado. Cuando se establece en off, inhabilita la validación de la cadena del cuerpo de la función durante CREATE FUNCTION. La desactivación de la validación evita los efectos secundarios del proceso de validación y evita los falsos positivos debido a problemas como las referencias directas. Establezca este parámetro en off antes de cargar funciones en nombre de otros usuarios; pg_dump lo hace automáticamente.

default_transaction_isolation (enum)

Cada transacción SQL tiene un nivel de aislamiento, que puede ser “leer no comprometido“, “leer comprometido“, “lectura repetible“, o “serializable“. Este parámetro controla el nivel de aislamiento predeterminado de cada nueva transacción. El valor predeterminado es “leer comprometido“.

Consultar Capítulo 13 y SET TRANSACTION para obtener más información.

default_transaction_read_only (boolean)

Una transacción SQL de solo lectura no puede alterar tablas no temporales. Este parámetro controla el estado de solo lectura predeterminado de cada nueva transacción. El valor predeterminado es off (leer escribir).

Consulte SET TRANSACTION para obtener más información.

default_transaction_deferrable (boolean)

Al correr en el serializable nivel de aislamiento, una transacción de SQL de solo lectura diferible puede retrasarse antes de que se le permita continuar. Sin embargo, una vez que comienza a ejecutarse, no incurre en ninguno de los gastos generales necesarios para garantizar la serialización; por lo que el código de serialización no tendrá ninguna razón para forzarlo a abortar debido a actualizaciones concurrentes, lo que hace que esta opción sea adecuada para transacciones de solo lectura de larga ejecución.

Este parámetro controla el estado diferible predeterminado de cada nueva transacción. Actualmente no tiene ningún efecto sobre las transacciones de lectura y escritura o aquellas que operan a niveles de aislamiento inferiores a serializable. El valor predeterminado es off.

Consulte SET TRANSACTION para obtener más información.

session_replication_role (enum)

Controla la activación de reglas y disparadores relacionados con la replicación para la sesión actual. La configuración de esta variable requiere privilegios de superusuario y da como resultado el descarte de cualquier plan de consulta previamente almacenado en caché. Los valores posibles son origin (el valor por defecto), replica y local.

El uso previsto de esta configuración es que los sistemas de replicación lógica lo establezcan en replica cuando están aplicando cambios replicados. El efecto de eso será que los activadores y las reglas (que no se hayan modificado de su configuración predeterminada) no se activarán en la réplica. Ver las cláusulas ALTER TABLE ENABLE TRIGGER y ENABLE RULE para más información.

PostgreSQL trata la configuración origin y local lo mismo internamente. Los sistemas de replicación de terceros pueden usar estos dos valores para sus propósitos internos, por ejemplo, usando local para designar una sesión cuyos cambios no se deben replicar.

Dado que las claves externas se implementan como desencadenadores, establecer este parámetro en replica también deshabilita todas las comprobaciones de claves foráneas, que pueden dejar los datos en un estado inconsistente si se usan incorrectamente.

statement_timeout (integer)

Anule cualquier declaración que requiera más tiempo del especificado. Si log_min_error_statement se establece en ERROR o inferior, también se registrará la declaración que agotó el tiempo de espera. Si este valor se especifica sin unidades, se toma como milisegundos. Un valor de cero (el predeterminado) deshabilita el tiempo de espera.

El tiempo de espera se mide desde el momento en que un comando llega al servidor hasta que el servidor lo completa. Si aparecen varias sentencias SQL en un solo mensaje de consulta simple, el tiempo de espera se aplica a cada sentencia por separado. (Las versiones de PostgreSQL anteriores a la 13 generalmente trataban el tiempo de espera como si se aplicara a toda la cadena de consulta). En el protocolo de consulta extendido, el tiempo de espera comienza a ejecutarse cuando llega cualquier mensaje relacionado con la consulta (Analizar, Vincular, Ejecutar, Describir) y se cancela al finalizar de un mensaje Execute o Sync.

Configuración statement_timeout en postgresql.conf no se recomienda porque afectaría a todas las sesiones.

lock_timeout (integer)

Abortar cualquier instrucción que espere más de la cantidad de tiempo especificada mientras intenta adquirir un bloqueo en una tabla, índice, fila u otro objeto de base de datos. El límite de tiempo se aplica por separado a cada intento de adquisición de bloqueo. El límite se aplica tanto a las solicitudes de bloqueo explícitas (como LOCK TABLE, o SELECT FOR UPDATE sin NOWAIT) y a las cerraduras adquiridas implícitamente. Si este valor se especifica sin unidades, se toma como milisegundos. Un valor de cero (el predeterminado) deshabilita la se acabó el tiempo.

diferente a statement_timeout, este tiempo de espera solo puede ocurrir mientras se esperan bloqueos. Tenga en cuenta que si statement_timeout es distinto de cero, es bastante inútil establecer lock_timeout al mismo valor o mayor, ya que el tiempo de espera de la sentencia siempre se dispararía primero. Si log_min_error_statement se establece en ERROR o inferior, se registrará la declaración que agotó el tiempo de espera.

Configuración lock_timeout en postgresql.conf no se recomienda porque afectaría a todas las sesiones.

idle_in_transaction_session_timeout (integer)

Termine cualquier sesión con una transacción abierta que haya estado inactiva por más de la cantidad de tiempo especificada. Esto permite liberar los bloqueos mantenidos por esa sesión y reutilizar la ranura de conexión; también permite que se vacíen las tuplas visibles solo para esta transacción. Consulte la Sección 24.1 para obtener más detalles sobre esto.

Si este valor se especifica sin unidades, se toma como milisegundos. Un valor de cero (el predeterminado) deshabilita el tiempo de espera.

vacuum_freeze_table_age (integer)

VACUUM realiza un escaneo agresivo si la tabla pg_class.relfrozenxid El campo ha alcanzado la edad especificada por esta configuración. Un escaneo agresivo difiere de uno regular VACUUM ya que visita todas las páginas que pueden contener XID o MXID no congelados, no solo aquellas que pueden contener tuplas muertas. El valor predeterminado es 150 millones de transacciones. Aunque los usuarios pueden establecer este valor entre cero y dos mil millones, VACUUM limitará silenciosamente el valor efectivo al 95% de autovacuum_freeze_max_age, de modo que un manual periódico VACUUM tiene la oportunidad de ejecutarse antes de que se lance un autovacío anti-envolvente para la mesa. Para obtener más información, consulte la Sección 24.1.5.

vacuum_freeze_min_age (integer)

Especifica la edad límite (en transacciones) que VACUUM debe usar para decidir si congelar las versiones de filas mientras se escanea una tabla. El valor predeterminado es 50 millones de transacciones. Aunque los usuarios pueden establecer este valor entre cero y mil millones, VACUUM limitará silenciosamente el valor efectivo a la mitad del valor de autovacuum_freeze_max_age, de modo que no haya un tiempo irrazonablemente corto entre autovacíos forzados. Para obtener más información, consulte la Sección 24.1.5.

vacuum_multixact_freeze_table_age (integer)

VACUUM realiza un escaneo agresivo si la tabla pg_class.relminmxid El campo ha alcanzado la edad especificada por esta configuración. Un escaneo agresivo difiere de uno regular VACUUM ya que visita todas las páginas que pueden contener XID o MXID no congelados, no solo aquellas que pueden contener tuplas muertas. El valor predeterminado es 150 millones de multixecturas. Aunque los usuarios pueden establecer este valor entre cero y dos mil millones, VACUUM limitará silenciosamente el valor efectivo al 95% de autovacuum_multixact_freeze_max_age, de modo que un manual periódico VACUUM tiene la oportunidad de ejecutarse antes de que se lance un anti-Wraparound para la mesa. Para obtener más información, consulte la Sección 24.1.5.1.

vacuum_multixact_freeze_min_age (integer)

Especifica la edad de corte (en multixectos) que VACUUM debe utilizar para decidir si se reemplazan los ID de multixact con un ID de transacción más reciente o un ID de multixact mientras se escanea una tabla. El valor predeterminado es de 5 millones de multixectos. Aunque los usuarios pueden establecer este valor entre cero y mil millones, VACUUM limitará silenciosamente el valor efectivo a la mitad del valor de autovacuum_multixact_freeze_max_age, para que no haya un tiempo irrazonablemente corto entre autovacíos forzados. Para obtener más información, consulte la Sección 24.1.5.1.

vacuum_cleanup_index_scale_factor (floating point)

Especifica la fracción del número total de tuplas de montón contadas en la colección de estadísticas anterior que se puede insertar sin incurrir en un escaneo de índice en el VACUUM etapa de limpieza. Actualmente, esta configuración solo se aplica a los índices de árbol B.

Si no se eliminaron tuplas del montón, los índices del árbol B aún se escanean en el VACUUM etapa de limpieza cuando se cumple al menos una de las siguientes condiciones: las estadísticas del índice están obsoletas o el índice contiene páginas eliminadas que se pueden reciclar durante la limpieza. Las estadísticas del índice se consideran obsoletas si el número de tuplas recién insertadas supera el vacuum_cleanup_index_scale_factor fracción del número total de tuplas de montón detectadas por la recopilación de estadísticas anterior. El número total de tuplas de montón se almacena en la metapágina del índice. Tenga en cuenta que la metapágina no incluye estos datos hasta VACUUM no encuentra tuplas muertas, por lo que el escaneo del índice del árbol B en la etapa de limpieza solo se puede omitir si el segundo y los siguientes VACUUM los ciclos no detectan tuplas muertas.

El valor puede oscilar entre 0 para 10000000000. Cuando vacuum_cleanup_index_scale_factor se establece en 0, las exploraciones de índice nunca se omiten durante VACUUM limpiar. El valor predeterminado es 0.1.

bytea_output (enum)

Establece el formato de salida para valores de tipo bytea. Los valores válidos son hex (el predeterminado) y escape (el formato tradicional de PostgreSQL). Consulte la Sección 8.4 para obtener más información. los bytea type siempre acepta ambos formatos en la entrada, independientemente de esta configuración.

xmlbinary (enum)

Establece cómo se codificarán los valores binarios en XML. Esto se aplica, por ejemplo, cuando bytea los valores son convertidos a XML por las funciones xmlelement o xmlforest. Los valores posibles son base64 y hex, ambos definidos en el estándar XML Schema. El valor predeterminado es base64. Para obtener más información sobre las funciones relacionadas con XML, consulte la Sección 9.15.

La elección real aquí es principalmente una cuestión de gustos, limitada solo por posibles restricciones en las aplicaciones del cliente. Ambos métodos admiten todos los valores posibles, aunque la codificación hexadecimal será algo mayor que la codificación base64.

xmloption (enum)

Establece si DOCUMENT o CONTENT está implícito al convertir entre XML y valores de cadena de caracteres. Consulte la Sección 8.13 para obtener una descripción de esto. Los valores válidos son DOCUMENT y CONTENT. El valor predeterminado es CONTENT.

Según el estándar SQL, el comando para configurar esta opción es

SET XML OPTION { DOCUMENT | CONTENT };

Esta sintaxis también está disponible en PostgreSQL.

gin_pending_list_limit (integer)

Establece el tamaño máximo de la lista pendiente de un índice GIN, que se utiliza cuando fastupdate está habilitado. Si la lista crece más allá de este tamaño máximo, se limpia moviendo las entradas a la estructura de datos GIN principal del índice en forma masiva. Si este valor se especifica sin unidades, se toma como kilobytes. El valor predeterminado es cuatro megabytes (4MB). Esta configuración se puede anular para índices GIN individuales cambiando los parámetros de almacenamiento de índices. Consulte la Sección 66.4.1 y la Sección 66.5 para obtener más información.

19.11.2. Configuración regional y formato

DateStyle (string)

Establece el formato de visualización para los valores de fecha y hora, así como las reglas para interpretar valores de entrada de fecha ambiguos. Por razones históricas, esta variable contiene dos componentes independientes: la especificación del formato de salida (ISO, Postgres, SQL, o German) y la especificación de entrada / salida para pedidos de año / mes / día (DMY, MDY, o YMD). Estos se pueden configurar por separado o juntos. Las palabras clave Euro y European son sinónimos de DMY; las palabras clave US, NonEuro, y NonEuropean son sinónimos de MDY. Consulte la Sección 8.5 para obtener más información. El valor predeterminado incorporado es ISO, MDY, pero initdb inicializará el archivo de configuración con una configuración que corresponda al comportamiento del elegido lc_time lugar.

IntervalStyle (enum)

Establece el formato de visualización para los valores de intervalo. El valor sql_standard producirá una salida que coincida con los literales de intervalo estándar de SQL. El valor postgres (que es el valor predeterminado) producirá una salida que coincida con las versiones de PostgreSQL anteriores a 8.4 cuando el parámetro DateStyle se estableció en ISO. El valor postgres_verbose producirá una salida que coincida con las versiones de PostgreSQL anteriores a la 8.4 cuando el DateStyle El parámetro se estableció en noISO producción. El valor iso_8601 producirá una salida que coincida con el intervalo de tiempo “formato con designadores“ definido en la sección 4.4.3.2 de ISO 8601.

los IntervalStyle El parámetro también afecta la interpretación de la entrada de intervalo ambiguo. Consulte la Sección 8.5.4 para obtener más información.

TimeZone (string)

Establece la zona horaria para mostrar e interpretar marcas de tiempo. El valor predeterminado incorporado es GMT, pero que normalmente se anula en postgresql.conf; initdb instalará allí una configuración correspondiente a su entorno de sistema. Consulte la Sección 8.5.3 para obtener más información.

timezone_abbreviations (string)

Establece la colección de abreviaturas de zona horaria que el servidor aceptará para la entrada de fecha y hora. El valor predeterminado es 'Default', que es una colección que funciona en la mayor parte del mundo; tambien hay 'Australia' y 'India', y se pueden definir otras colecciones para una instalación en particular. Consulte la Sección B.4 para obtener más información.

extra_float_digits (integer)

Este parámetro ajusta el número de dígitos usados ​​para la salida textual de valores de punto flotante, incluyendo float4, float8y tipos de datos geométricos.

Si el valor es 1 (el predeterminado) o superior, los valores flotantes se emiten en el formato más corto y preciso; consulte la Sección 8.1.3. El número real de dígitos generados depende solo del valor que se emite, no del valor de este parámetro. Se requieren como máximo 17 dígitos para float8 valores, y 9 para float4 valores. Este formato es rápido y preciso, conservando el valor flotante binario original exactamente cuando se lee correctamente. Para compatibilidad histórica, se permiten valores de hasta 3.

Si el valor es cero o negativo, la salida se redondea a una precisión decimal determinada. La precisión utilizada es el número estándar de dígitos para el tipo (FLT_DIG o DBL_DIG según corresponda) reducido de acuerdo con el valor de este parámetro. (Por ejemplo, especificar -1 provocará float4 valores que se van a generar redondeados a 5 dígitos significativos, y float8 valores redondeados a 14 dígitos.) Este formato es más lento y no conserva todos los bits del valor flotante binario, pero puede ser más legible por humanos.

Nota

El significado de este parámetro y su valor predeterminado cambió en PostgreSQL 12; consulte la Sección 8.1.3 para obtener más información.

client_encoding (string)

Establece la codificación del lado del cliente (juego de caracteres). El valor predeterminado es utilizar la codificación de la base de datos. Los conjuntos de caracteres admitidos por el servidor PostgreSQL se describen en la Sección 23.3.1.

lc_messages (string)

Establece el idioma en el que se muestran los mensajes. Los valores aceptables dependen del sistema; consulte la Sección 23.1 para obtener más información. Si esta variable se establece en la cadena vacía (que es la predeterminada), el valor se hereda del entorno de ejecución del servidor de una manera dependiente del sistema.

En algunos sistemas, esta categoría de configuración regional no existe. La configuración de esta variable seguirá funcionando, pero no tendrá ningún efecto. Además, existe la posibilidad de que no existan mensajes traducidos para el idioma deseado. En ese caso, seguirá viendo los mensajes en inglés.

Solo los superusuarios pueden cambiar esta configuración, ya que afecta los mensajes enviados al registro del servidor y al cliente, y un valor incorrecto puede oscurecer la legibilidad de los registros del servidor.

lc_monetary (string)

Establece la configuración regional que se utilizará para formatear los importes monetarios, por ejemplo, con el to_char familia de funciones. Los valores aceptables dependen del sistema; consulte la Sección 23.1 para obtener más información. Si esta variable se establece en la cadena vacía (que es el valor predeterminado), el valor se hereda del entorno de ejecución del servidor de forma dependiente del sistema.

lc_numeric (string)

Establece la configuración regional que se utilizará para formatear números, por ejemplo, con el to_char familia de funciones. Los valores aceptables dependen del sistema; consulte la Sección 23.1 para obtener más información. Si esta variable se establece en la cadena vacía (que es la predeterminada), el valor se hereda del entorno de ejecución del servidor de una manera dependiente del sistema.

lc_time (string)

Establece la configuración regional que se utilizará para formatear fechas y horas, por ejemplo, con el to_char familia de funciones. Los valores aceptables dependen del sistema; consulte la Sección 23.1 para obtener más información. Si esta variable se establece en la cadena vacía (que es la predeterminada), el valor se hereda del entorno de ejecución del servidor de una manera dependiente del sistema.

default_text_search_config (string)

Selecciona la configuración de búsqueda de texto que utilizan aquellas variantes de las funciones de búsqueda de texto que no tienen un argumento explícito que especifique la configuración. Ver Capítulo 12 para mayor información. El valor predeterminado incorporado es pg_catalog.simple, pero initdb inicializará el archivo de configuración con una configuración que corresponda a la elegida lc_ctype locale, si se puede identificar una configuración que coincida con esa locale.

19.11.3. Precarga de biblioteca compartida

Hay varias configuraciones disponibles para precargar bibliotecas compartidas en el servidor, con el fin de cargar funcionalidades adicionales o lograr beneficios de rendimiento. Por ejemplo, un ajuste de '$libdir/mylib' causaría mylib.so (o en algunas plataformas, mylib.sl) para ser precargado desde el directorio de biblioteca estándar de la instalación. Las diferencias entre las configuraciones son cuándo entran en vigencia y qué privilegios se requieren para cambiarlas.

Las bibliotecas de lenguaje de procedimiento de PostgreSQL se pueden precargar de esta manera, generalmente usando la sintaxis '$libdir/plXXX' dónde XXX es pgsql, perl, tcl, o python.

Solo las bibliotecas compartidas diseñadas específicamente para usarse con PostgreSQL se pueden cargar de esta manera. Cada biblioteca compatible con PostgreSQL tiene una “bloque mágico“ que se comprueba para garantizar la compatibilidad. Por esta razón, las bibliotecas que no son de PostgreSQL no se pueden cargar de esta manera. Es posible que pueda utilizar las funciones del sistema operativo, como LD_PRELOAD para eso.

En general, consulte la documentación de un módulo específico para conocer la forma recomendada de cargar ese módulo.

local_preload_libraries (string)

Esta variable especifica una o más bibliotecas compartidas que se precargarán al inicio de la conexión. Contiene una lista de nombres de bibliotecas separados por comas, donde cada nombre se interpreta como el comando LOAD. Se ignoran los espacios en blanco entre las entradas; rodee el nombre de una biblioteca con comillas dobles si necesita incluir espacios en blanco o comas en el nombre. El valor del parámetro solo tiene efecto al inicio de la conexión. Los cambios posteriores no tienen ningún efecto. Si no se encuentra una biblioteca especificada, el intento de conexión fallará.

Esta opción puede ser configurada por cualquier usuario. Por eso, las bibliotecas que se pueden cargar están restringidas a las que aparecen en el plugins subdirectorio del directorio de la biblioteca estándar de la instalación. (Es responsabilidad del administrador de la base de datos asegurarse de que solo “a salvo“ las bibliotecas están instaladas allí). local_preload_libraries puede especificar este directorio explícitamente, por ejemplo $libdir/plugins/mylib, o simplemente especifique el nombre de la biblioteca – mylib tendría el mismo efecto que $libdir/plugins/mylib.

La intención de esta función es permitir que los usuarios sin privilegios carguen bibliotecas de depuración o de medición del rendimiento en sesiones específicas sin necesidad de una LOAD mando. Con ese fin, sería típico establecer este parámetro utilizando el PGOPTIONS variable de entorno en el cliente o utilizando ALTER ROLE SET.

Sin embargo, a menos que un módulo esté diseñado específicamente para ser utilizado de esta manera por personas que no son superusuarios, esta no suele ser la configuración adecuada. En su lugar, mire session_preload_libraries.

session_preload_libraries (string)

Esta variable especifica una o más bibliotecas compartidas que se precargarán al inicio de la conexión. Contiene una lista de nombres de bibliotecas separados por comas, donde cada nombre se interpreta como el comando LOAD. Se ignoran los espacios en blanco entre las entradas; rodee el nombre de una biblioteca con comillas dobles si necesita incluir espacios en blanco o comas en el nombre. El valor del parámetro solo tiene efecto al inicio de la conexión. Los cambios posteriores no tienen ningún efecto. Si no se encuentra una biblioteca especificada, el intento de conexión fallará. Solo los superusuarios pueden cambiar esta configuración.

La intención de esta función es permitir que las bibliotecas de depuración o medición del rendimiento se carguen en sesiones específicas sin una necesidad explícita LOAD orden que se está dando. Por ejemplo, auto_explain podría habilitarse para todas las sesiones bajo un nombre de usuario dado estableciendo este parámetro con ALTER ROLE SET. Además, este parámetro se puede cambiar sin reiniciar el servidor (pero los cambios solo tienen efecto cuando se inicia una nueva sesión), por lo que es más fácil agregar nuevos módulos de esta manera, incluso si deberían aplicarse a todas las sesiones.

A diferencia de shared_preload_libraries, no hay una gran ventaja de rendimiento al cargar una biblioteca al inicio de la sesión en lugar de cuando se usa por primera vez. Sin embargo, hay algunas ventajas cuando se utiliza la agrupación de conexiones.

shared_preload_libraries (string)

Esta variable especifica una o más bibliotecas compartidas que se precargarán al iniciar el servidor. Contiene una lista de nombres de bibliotecas separados por comas, donde cada nombre se interpreta como el comando LOAD. Se ignoran los espacios en blanco entre las entradas; rodee el nombre de una biblioteca con comillas dobles si necesita incluir espacios en blanco o comas en el nombre. Este parámetro solo se puede configurar al iniciar el servidor. Si no se encuentra una biblioteca especificada, el servidor no podrá iniciarse.

Algunas bibliotecas necesitan realizar ciertas operaciones que solo pueden tener lugar al inicio de postmaster, como asignar memoria compartida, reservar bloqueos ligeros o iniciar trabajadores en segundo plano. Esas bibliotecas deben cargarse al inicio del servidor a través de este parámetro. Consulte la documentación de cada biblioteca para obtener más detalles.

También se pueden precargar otras bibliotecas. Al precargar una biblioteca compartida, se evita el tiempo de inicio de la biblioteca cuando se utiliza por primera vez. Sin embargo, el tiempo para iniciar cada nuevo proceso de servidor puede aumentar ligeramente, incluso si ese proceso nunca usa la biblioteca. Por lo tanto, este parámetro se recomienda solo para las bibliotecas que se utilizarán en la mayoría de las sesiones. Además, cambiar este parámetro requiere reiniciar el servidor, por lo que esta no es la configuración correcta para usar en tareas de depuración a corto plazo, por ejemplo. Use session_preload_libraries para eso en su lugar.

Nota

En los hosts de Windows, la precarga de una biblioteca al inicio del servidor no reducirá el tiempo necesario para iniciar cada nuevo proceso del servidor; cada proceso del servidor volverá a cargar todas las bibliotecas precargadas. Sin embargo, shared_preload_libraries sigue siendo útil en hosts de Windows para bibliotecas que necesitan realizar operaciones en el momento de inicio de postmaster.

jit_provider (string)

Esta variable es el nombre de la biblioteca del proveedor JIT que se utilizará (consulte la Sección 31.4.2). El valor predeterminado es llvmjit. Este parámetro solo se puede configurar al iniciar el servidor.

Si se establece en una biblioteca inexistente, JIT no estará disponible, pero no se generará ningún error. Esto permite que el soporte JIT se instale por separado del paquete principal de PostgreSQL.

19.11.4. Otros valores predeterminados

dynamic_library_path (string)

Si es necesario abrir un módulo cargable dinámicamente y el nombre de archivo especificado en el CREATE FUNCTION o LOAD El comando no tiene un componente de directorio (es decir, el nombre no contiene una barra), el sistema buscará en esta ruta el archivo requerido.

El valor de dynamic_library_path debe ser una lista de rutas de directorio absolutas separadas por dos puntos (o punto y coma en Windows). Si un elemento de la lista comienza con la cadena especial $libdir, el directorio de la biblioteca de paquetes de PostgreSQL compilado se sustituye por $libdir; aquí es donde se instalan los módulos proporcionados por la distribución estándar de PostgreSQL. (Usar pg_config --pkglibdir para averiguar el nombre de este directorio). Por ejemplo:

dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'

o, en un entorno Windows:

dynamic_library_path = 'C:toolspostgresql;H:my_projectlib;$libdir'

El valor predeterminado para este parámetro es '$libdir'. Si el valor se establece en una cadena vacía, la búsqueda de ruta automática se desactiva.

Los superusuarios pueden cambiar este parámetro en tiempo de ejecución, pero una configuración realizada de esa manera solo persistirá hasta el final de la conexión del cliente, por lo que este método debe reservarse para fines de desarrollo. La forma recomendada de configurar este parámetro es en el postgresql.conf archivo de configuración.

gin_fuzzy_search_limit (integer)

Límite superior suave del tamaño del conjunto devuelto por los escaneos de índice GIN. Para obtener más información, consulte la Sección 66.5.