wal_level determina cuánta información se escribe en el WAL. El valor predeterminado es replica, que escribe suficiente información para soportar el archivo del WAL y la replicación, incluyendo la ejecución de consultas de solo lectura en un servidor en espera. minimal elimina todo el registro excepto la información necesaria para recuperarse de una caída del servidor o un apagado inmediato. Finalmente, logical añade la información necesaria para soportar la decodificación lógica. Cada nivel incluye la información registrada en todos los niveles inferiores. Este parámetro solo se puede establecer al inicio del servidor.

El nivel minimal genera el menor volumen de WAL. No registra información de filas para relaciones permanentes en transacciones que las crean o las reescriben. Esto puede hacer que las operaciones sean mucho más rápidas (consulta la Section 14.4.7). Las operaciones que inician esta optimización incluyen:

Sin embargo, el WAL mínimo no contiene información suficiente para la recuperación ante desastres en un punto en el tiempo (point-in-time recovery), por lo que se debe usar replica o superior para habilitar el archivado continuo (archive_mode) y la replicación binaria en streaming. De hecho, el servidor ni siquiera se iniciará en este modo si max_wal_senders no es cero. Ten en cuenta que cambiar wal_level a minimal hace que las copias de seguridad base anteriores queden inutilizables para la recuperación en un punto en el tiempo y los servidores en espera.

En el nivel logical, se registra la misma información que con replica, además de la información necesaria para extraer conjuntos de cambios lógicos del WAL. Usar un nivel de logical aumentará el volumen del WAL, particularmente si muchas tablas están configuradas para REPLICA IDENTITY FULL y se ejecutan muchas sentencias UPDATE y DELETE.

En versiones anteriores a la 9.6, este parámetro también permitía los valores archive y hot_standby. Estos todavía se aceptan pero se mapean a replica.

Si este parámetro está activo, el servidor de PostgreSQL intentará asegurarse de que las actualizaciones se escriban físicamente en el disco, mediante llamadas al sistema fsync() o varios métodos equivalentes (consulta la wal_sync_method). Esto garantiza que el clúster de la base de datos pueda recuperarse a un estado consistente después de una caída del sistema operativo o del hardware.

Aunque desactivar fsync a menudo supone un beneficio de rendimiento, esto puede resultar en una corrupción de datos irrecuperable en caso de un corte de energía o una caída del sistema. Por lo tanto, solo es aconsejable desactivar fsync si puedes recrear fácilmente toda tu base de datos a partir de datos externos.

Ejemplos de circunstancias seguras para desactivar fsync incluyen la carga inicial de un nuevo clúster de base de datos desde un archivo de copia de seguridad, el uso de un clúster de base de datos para procesar un lote de datos después del cual la base de datos se desechará y se volverá a crear, o para un clon de base de datos de solo lectura que se recrea con frecuencia y no se utiliza para failover. El hardware de alta calidad por sí solo no es una justificación suficiente para desactivar fsync.

Para una recuperación fiable al cambiar fsync de apagado a encendido, es necesario forzar todos los búferes modificados en el kernel al almacenamiento duradero. Esto se puede hacer mientras el clúster está apagado o mientras fsync está encendido ejecutando initdb --sync-only, ejecutando sync, desmontando el sistema de archivos o reiniciando el servidor.

En muchas situaciones, desactivar synchronous_commit para transacciones no críticas puede proporcionar gran parte del beneficio potencial de rendimiento de desactivar fsync, sin los riesgos asociados de corrupción de datos.

fsync solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. Si desactivas este parámetro, considera también desactivar full_page_writes.

Especifica cuánto procesamiento del WAL debe completarse antes de que el servidor de base de datos devuelva una indicación de “éxito” al cliente. Los valores válidos son remote_apply, on (el valor predeterminado), remote_write, local y off.

Si synchronous_standby_names está vacío, las únicas configuraciones significativas son on y off; remote_apply, remote_write y local proporcionan el mismo nivel de sincronización local que on. El comportamiento local de todos los modos distintos de off es esperar al vaciado (flush) local del WAL al disco. En el modo off, no hay espera, por lo que puede haber un retraso entre el momento en que se reporta el éxito al cliente y el momento en que la transacción se garantiza posteriormente como segura contra una caída del servidor. (El retraso máximo es tres veces el valor de wal_writer_delay). A diferencia de fsync, establecer este parámetro en off no crea ningún riesgo de inconsistencia en la base de datos: una caída del sistema operativo o de la base de datos podría resultar en la pérdida de algunas transacciones recientemente supuestamente confirmadas, pero el estado de la base de datos será exactamente el mismo que si esas transacciones se hubieran abortado limpiamente. Por lo tanto, desactivar synchronous_commit puede ser una alternativa útil cuando el rendimiento es más importante que la certeza exacta sobre la durabilidad de una transacción. Para más detalles, consulta la Section 28.4.

Si synchronous_standby_names no está vacío, synchronous_commit también controla si los commits de transacciones esperarán a que sus registros del WAL sean procesados en los servidores en espera (standby).

Cuando se establece en remote_apply, los commits esperarán hasta que las respuestas de los servidores en espera síncronos actuales indiquen que han recibido el registro de commit de la transacción y lo han aplicado, de modo que se ha vuelto visible para las consultas en los servidores en espera, y también se ha escrito en el almacenamiento duradero en los mismos. Esto causará retrasos de commit mucho mayores que las configuraciones anteriores, ya que espera a la reproducción del WAL. Cuando se establece en on, los commits esperan hasta que las respuestas de los servidores en espera síncronos actuales indiquen que han recibido el registro de commit de la transacción y lo han vaciado al almacenamiento duradero. Esto garantiza que la transacción no se perderá a menos que tanto el servidor primario como todos los servidores en espera síncronos sufran una corrupción de su almacenamiento de base de datos. Cuando se establece en remote_write, los commits esperarán hasta que las respuestas de los servidores en espera síncronos actuales indiquen que han recibido el registro de commit de la transacción y lo han escrito en sus sistemas de archivos. Esta configuración garantiza la preservación de los datos si una instancia en espera de PostgreSQL se cae, pero no si la instancia en espera sufre una caída a nivel del sistema operativo, porque los datos no han llegado necesariamente al almacenamiento duradero en el servidor en espera. La configuración local hace que los commits esperen al vaciado local al disco, pero no a la replicación. Esto no suele ser deseable cuando se utiliza la replicación síncrona, pero se proporciona por completitud.

Este parámetro se puede cambiar en cualquier momento; el comportamiento para cualquier transacción se determina por la configuración vigente en el momento en que se confirma (commit). Por lo tanto, es posible, y útil, que algunas transacciones se confirmen de forma síncrona y otras de forma asíncrona. Por ejemplo, para hacer que una sola transacción de múltiples sentencias se confirme asíncronamente cuando el valor predeterminado es el opuesto, ejecuta SET LOCAL synchronous_commit TO OFF dentro de la transacción.

La Table 19.1 resume las capacidades de las configuraciones de synchronous_commit.

Método utilizado para forzar las actualizaciones del WAL al disco. Si fsync está desactivado, esta configuración es irrelevante, ya que las actualizaciones de los archivos del WAL no se forzarán en absoluto. Los valores posibles son:

No todas estas opciones están disponibles en todas las plataformas. La opción predeterminada es el primer método de la lista anterior que sea soportado por la plataforma, excepto que fdatasync es el predeterminado en Linux y FreeBSD. El valor predeterminado no es necesariamente el ideal; podría ser necesario cambiar esta configuración u otros aspectos de la configuración de tu sistema para crear una configuración segura contra caídas u obtener el rendimiento óptimo. Estos aspectos se analizan en la Section 28.1. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Cuando este parámetro está activado, el servidor de PostgreSQL escribe el contenido completo de cada página de disco en el WAL durante la primera modificación de esa página después de un checkpoint. Esto es necesario porque una escritura de página que está en proceso durante una caída del sistema operativo podría completarse solo parcialmente, dando lugar a una página en disco que contiene una mezcla de datos antiguos y nuevos. Los datos de cambio a nivel de fila que normalmente se almacenan en el WAL no serán suficientes para restaurar por completo dicha página durante la recuperación tras una caída. Almacenar la imagen completa de la página garantiza que la página se pueda restaurar correctamente, pero a costa de aumentar la cantidad de datos que deben escribirse en el WAL. (Dado que la reproducción del WAL siempre comienza desde un checkpoint, es suficiente hacer esto durante el primer cambio de cada página después de un checkpoint. Por lo tanto, una forma de reducir el coste de las escrituras de página completa es aumentar los parámetros del intervalo de checkpoint).

Desactivar este parámetro acelera el funcionamiento normal, pero podría provocar una corrupción de datos irrecuperable o una corrupción silenciosa de datos tras un fallo del sistema. Los riesgos son similares a desactivar fsync, aunque menores, y solo debe desactivarse bajo las mismas circunstancias recomendadas para ese parámetro.

Desactivar este parámetro no afecta al uso del archivado del WAL para la recuperación en un punto en el tiempo (PITR) (consulta la Section 25.3).

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. El valor predeterminado es on.

Cuando este parámetro es on, el servidor de PostgreSQL escribe el contenido completo de cada página de disco en el WAL durante la primera modificación de esa página después de un checkpoint, incluso para modificaciones no críticas de los llamados hint bits (bits de pista).

Si las sumas de comprobación de datos (checksums) están habilitadas, las actualizaciones de los hint bits siempre se registran en el WAL y esta configuración se ignora. Puedes usar esta configuración para probar cuánta escritura adicional en el WAL ocurriría si tu base de datos tuviera habilitadas las sumas de comprobación de datos.

Este parámetro solo se puede establecer al inicio del servidor. El valor predeterminado es off.

Este parámetro habilita la compresión del WAL utilizando el método de compresión especificado. Cuando está habilitado, el servidor de PostgreSQL comprime las imágenes de página completa escritas en el WAL (por ejemplo, cuando full_page_writes está activado, durante una copia de seguridad base, etc.). Una imagen de página comprimida se descomprimirá durante la reproducción del WAL. Los métodos soportados son pglz, lz4 (si PostgreSQL se compiló con --with-lz4) y zstd (si PostgreSQL se compiló con --with-zstd). El valor predeterminado es off. Solo los superusuarios y los usuarios con el privilegio SET adecuado pueden cambiar esta configuración.

Habilitar la compresión puede reducir el volumen del WAL sin aumentar el riesgo de corrupción irrecuperable de datos, pero a costa de un poco de CPU adicional dedicada a la compresión durante el registro en el WAL y a la descompresión durante la reproducción del WAL.

Si se establece en on (el valor predeterminado), esta opción hace que los nuevos archivos del WAL se llenen con ceros. En algunos sistemas de archivos, esto garantiza que se asigne espacio antes de que necesitemos escribir registros en el WAL. Sin embargo, los sistemas de archivos con Copy-On-Write (COW) pueden no beneficiarse de esta técnica, por lo que se proporciona la opción de omitir este trabajo innecesario. Si se establece en off, solo se escribe el último byte cuando se crea el archivo para que tenga el tamaño esperado.

Si se establece en on (el valor predeterminado), esta opción hace que los archivos del WAL se reciclen renombrándolos, evitando la necesidad de crear otros nuevos. En los sistemas de archivos COW, puede ser más rápido crear otros nuevos, por lo que se proporciona la opción de desactivar este comportamiento.

La cantidad de memoria compartida utilizada para los datos del WAL que aún no han sido escritos en el disco. La configuración predeterminada de -1 selecciona un tamaño igual a 1/32 (aproximadamente el 3%) de shared_buffers, pero no menos de 64kB ni más del tamaño de un segmento del WAL, normalmente 16MB. Este valor se puede configurar manualmente si la elección automática es demasiado grande o demasiado pequeña, pero cualquier valor positivo menor de 32kB se tratará como 32kB. Si este valor se especifica sin unidades, se toma como bloques del WAL, es decir, XLOG_BLCKSZ bytes, normalmente 8kB. Este parámetro solo se puede establecer al inicio del servidor.

El contenido de los búferes del WAL se escribe en el disco en cada commit de transacción, por lo que es poco probable que valores extremadamente grandes proporcionen un beneficio significativo. Sin embargo, establecer este valor en al menos unos pocos megabytes puede mejorar el rendimiento de escritura en un servidor muy activo donde muchos clientes están confirmando transacciones a la vez. El ajuste automático seleccionado por la configuración predeterminada de -1 debería dar resultados razonables en la mayoría de los casos.

Especifica la frecuencia con la que el escritor del WAL realiza el vaciado (flush) del WAL, en términos de tiempo. Después de vaciar el WAL, el escritor duerme durante la cantidad de tiempo indicada por wal_writer_delay, a menos que sea despertado antes por una transacción que se confirme de forma asíncrona. Si el último vaciado ocurrió hace menos de wal_writer_delay y se ha producido menos de wal_writer_flush_after de WAL desde entonces, entonces el WAL solo se escribe en el sistema operativo, no se vacía en el disco. Si este valor se especifica sin unidades, se toma como milisegundos. El valor predeterminado es 200 milisegundos (200ms). Ten en cuenta que en algunos sistemas, la resolución efectiva de los retrasos de sueño es de 10 milisegundos; establecer wal_writer_delay en un valor que no sea múltiplo de 10 podría tener los mismos resultados que establecerlo en el siguiente múltiplo superior de 10. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica la frecuencia con la que el escritor del WAL realiza el vaciado (flush) del WAL, en términos de volumen. Si el último vaciado ocurrió hace menos de wal_writer_delay y se ha producido menos de wal_writer_flush_after de WAL desde entonces, entonces el WAL solo se escribe en el sistema operativo, no se vacía en el disco. Si wal_writer_flush_after se establece en 0, entonces los datos del WAL siempre se vacían inmediatamente. Si este valor se especifica sin unidades, se toma como bloques del WAL, es decir, XLOG_BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 1MB. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Cuando wal_level es minimal y una transacción se confirma después de crear o reescribir una relación permanente, esta configuración determina cómo persistir los nuevos datos. Si los datos son más pequeños que esta configuración, se escriben en el registro del WAL; de lo contrario, se utiliza un fsync de los archivos afectados. Dependiendo de las propiedades de tu almacenamiento, aumentar o disminuir este valor podría ayudar si tales commits están ralentizando las transacciones concurrentes. Si este valor se especifica sin unidades, se toma como kilobytes. El valor predeterminado es de dos megabytes (2MB).

Establecer commit_delay añade un retraso de tiempo antes de que se inicie un vaciado del WAL. Esto puede mejorar el rendimiento de commit en grupo al permitir que un mayor número de transacciones se confirmen mediante un único vaciado del WAL, si la carga del sistema es lo suficientemente alta como para que las transacciones adicionales estén listas para confirmarse dentro del intervalo dado. Sin embargo, también aumenta la latencia en hasta el valor de commit_delay para cada vaciado del WAL. Debido a que el retraso simplemente se desperdicia si no hay otras transacciones listas para confirmarse, el retraso solo se realiza si al menos commit_siblings otras transacciones están activas cuando se va a iniciar un vaciado. Además, no se realizan retrasos si fsync está desactivado. Si este valor se especifica sin unidades, se toma como microsegundos. El valor predeterminado de commit_delay es cero (sin retraso). Solo los superusuarios y los usuarios con el privilegio SET adecuado pueden cambiar esta configuración.

En versiones de PostgreSQL anteriores a la 9.3, commit_delay se comportaba de manera diferente y era mucho menos efectivo: afectaba solo a los commits, en lugar de a todos los vaciados del WAL, y esperaba la totalidad del retraso configurado incluso si el vaciado del WAL se completaba antes. A partir de PostgreSQL 9.3, el primer proceso que está listo para vaciar espera el intervalo configurado, mientras que los procesos posteriores esperan solo hasta que el líder completa la operación de vaciado.

Número mínimo de transacciones concurrentes abiertas requeridas antes de realizar el retraso commit_delay. Un valor más grande hace más probable que al menos otra transacción esté lista para confirmarse durante el intervalo de retraso. El valor predeterminado es de cinco transacciones.

Tiempo máximo entre checkpoints automáticos del WAL. Si este valor se especifica sin unidades, se toma como segundos. El rango válido está entre 30 segundos y un día. El valor predeterminado es de cinco minutos (5min). Aumentar este parámetro puede incrementar la cantidad de tiempo necesario para la recuperación tras una caída del servidor. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica el objetivo de finalización del checkpoint, como una fracción del tiempo total entre checkpoints. El valor predeterminado es 0.9, lo que distribuye el checkpoint a lo largo de casi todo el intervalo disponible, proporcionando una carga de E/S bastante consistente y dejando al mismo tiempo algo de tiempo para los gastos generales de finalización del checkpoint. No se recomienda reducir este parámetro porque hace que el checkpoint se complete más rápido. Esto da como resultado una mayor tasa de E/S durante el checkpoint seguida de un período de menos E/S entre la finalización del checkpoint y el siguiente programado. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Cada vez que se haya escrito más de esta cantidad de datos al realizar un checkpoint, intenta forzar al sistema operativo a emitir estas escrituras al almacenamiento subyacente. Hacerlo limitará la cantidad de datos sucios en la caché de páginas del kernel, reduciendo la probabilidad de bloqueos cuando se emite un fsync al final del checkpoint, o cuando el sistema operativo escribe datos en lotes más grandes en segundo plano. A menudo, eso dará como resultado una latencia de transacción muy reducida, pero también hay algunos casos, especialmente con cargas de trabajo que son mayores que shared_buffers pero menores que la caché de páginas del sistema operativo, donde el rendimiento podría degradarse. Esta configuración puede no tener efecto en algunas plataformas. Si este valor se especifica sin unidades, es tomado como bloques, es decir, BLCKSZ bytes, típicamente 8kB. El rango válido está entre 0, que deshabilita la escritura forzada, y 2MB. El valor predeterminado es 256kB en Linux, 0 en otros lugares. (Si BLCKSZ no es 8kB, los valores predeterminado y máximo se escalan proporcionalmente a este). Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Escribe un mensaje en el registro del servidor si los checkpoints causados por el llenado de los archivos de segmento del WAL ocurren más cerca entre sí que esta cantidad de tiempo (lo que sugiere que max_wal_size debería elevarse). Si este valor se especifica sin unidades, se toma como segundos. El valor predeterminado es de 30 segundos (30s). El valor cero desactiva la advertencia. No se generarán advertencias si checkpoint_timeout es menor que checkpoint_warning. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Tamaño máximo que se permite que crezca el WAL durante checkpoints automáticos. Este es un límite blando; el tamaño del WAL puede superar max_wal_size bajo circunstancias especiales, como una carga pesada, un fallo en el archive_command o archive_library, o una configuración alta de wal_keep_size. Si este valor se especifica sin unidades, se toma como megabytes. El valor predeterminado es 1 GB. Aumentar este parámetro puede incrementar la cantidad de tiempo necesaria para la recuperación tras una caída del servidor. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Mientras el uso del disco por el WAL se mantenga por debajo de esta configuración, los archivos antiguos del WAL siempre se reciclarán para su uso futuro en un checkpoint, en lugar de eliminarse. Esto se puede usar para garantizar que se reserve suficiente espacio del WAL para manejar picos en el uso del WAL, por ejemplo, al ejecutar trabajos grandes por lotes. Si este valor se especifica sin unidades, se toma como megabytes. El valor predeterminado es 80 MB. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Cuando archive_mode está habilitado, los segmentos del WAL completados se envían al almacenamiento de archivo configurando archive_command o archive_library. Además de off, para deshabilitarlo, existen dos modos: on y always. Durante el funcionamiento normal, no hay diferencia entre los dos modos, pero cuando se establece en always el archivador del WAL también se habilita durante la recuperación del archivo o en el modo standby (en espera). En el modo always, todos los archivos restaurados desde el archivo o transmitidos mediante replicación en streaming serán archivados (nuevamente). Consulta la Section 26.2.9 para obtener más detalles.

archive_mode es una configuración independiente de archive_command y archive_library para que archive_command y archive_library se puedan cambiar sin salir del modo de archivado. Este parámetro solo se puede establecer al inicio del servidor. archive_mode no se puede habilitar cuando wal_level está configurado en minimal.

El comando de shell local a ejecutar para archivar un segmento de archivo del WAL completado. Cualquier %p en la cadena se reemplaza por el nombre de la ruta del archivo a archivar, y cualquier %f se reemplaza únicamente por el nombre del archivo. (El nombre de la ruta es relativo al directorio de trabajo del servidor, es decir, al directorio de datos del clúster). Utiliza %% para incrustar un carácter % real en el comando. Es importante que el comando devuelva un estado de salida cero solo si tiene éxito. Para más información, consulta la Section 25.3.1.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. Solo se utiliza si archive_mode fue habilitado al inicio del servidor y archive_library está configurada como una cadena vacía. Si tanto archive_command como archive_library están configurados, se producirá un error. Si archive_command es una cadena vacía (el valor predeterminado) mientras archive_mode está habilitado (y archive_library está configurada como una cadena vacía), el archivado del WAL se desactiva temporalmente, pero el servidor continúa acumulando archivos de segmento del WAL con la expectativa de que pronto se proporcione un comando. Configurar archive_command a un comando que no hace nada excepto devolver true, por ejemplo, /bin/true (REM en Windows), desactiva eficazmente el archivado, pero también rompe la cadena de archivos del WAL necesarios para la recuperación del archivo, por lo que solo debe usarse en circunstancias inusuales.

La biblioteca a utilizar para archivar los segmentos de archivos del WAL completados. Si se establece como una cadena vacía (el valor predeterminado), se habilita el archivado a través de la shell y se utiliza archive_command. Si tanto archive_command como archive_library están configurados, se producirá un error. De lo contrario, se utiliza la biblioteca compartida especificada para el archivado. El proceso del archivador del WAL es reiniciado por el postmaster cuando este parámetro cambia. Para obtener más información, consulta la Section 25.3.1 y la Chapter 49.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

El archive_command o la archive_library solo se invocan para los segmentos del WAL completados. Por lo tanto, si tu servidor genera poco tráfico de WAL (o tiene períodos de inactividad en los que lo hace), podría haber un largo retraso entre la finalización de una transacción y su registro seguro en el almacenamiento de archivo. Para limitar la antigüedad de los datos no archivados, puedes configurar archive_timeout para forzar al servidor a cambiar a un nuevo archivo de segmento del WAL periódicamente. Cuando este parámetro es mayor que cero, el servidor cambiará a un nuevo archivo de segmento cada vez que haya transcurrido esta cantidad de tiempo desde el último cambio de archivo de segmento, y haya habido alguna actividad en la base de datos, incluyendo un solo checkpoint (los checkpoints se omiten si no hay actividad en la base de datos). Ten en cuenta que los archivos archivados que se cierran anticipadamente debido a un cambio forzado siguen teniendo la misma longitud que los archivos completamente llenos. Por lo tanto, no es aconsejable usar un archive_timeout muy corto; esto inflará tu almacenamiento de archivo. Los valores de archive_timeout de un minuto más o menos suelen ser razonables. Deberías considerar el uso de la replicación en streaming, en lugar del archivado, si deseas que los datos se copien fuera del servidor primario más rápidamente que eso. Si este valor se especifica sin unidades, se toma como segundos. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Indica si se debe intentar la lectura anticipada (prefetch) durante la recuperación de los bloques referenciados en el WAL que aún no están en el buffer pool. Los valores válidos son off, on y try (el valor predeterminado). La configuración try habilita la lectura anticipada solo si el sistema operativo proporciona soporte para emitir consejos de lectura anticipada (read-ahead).

La lectura anticipada de los bloques que pronto se necesitarán puede reducir los tiempos de espera de E/S durante la recuperación con algunas cargas de trabajo. Consulta también las configuraciones wal_decode_buffer_size y maintenance_io_concurrency, que limitan la actividad de lectura anticipada.

Un límite sobre qué tan adelante puede buscar el servidor en el WAL para encontrar bloques para lectura anticipada. Si este valor se especifica sin unidades, se toma como bytes. El valor predeterminado es 512kB. Este parámetro solo se puede establecer al inicio del servidor.

El comando de shell local a ejecutar para recuperar un segmento archivado de la serie de archivos del WAL. Este parámetro es obligatorio para la recuperación de archivos, pero opcional para la replicación en streaming. Cualquier %f en la cadena se reemplaza por el nombre del archivo a recuperar del archivo, y cualquier %p se reemplaza por el nombre de la ruta de destino de la copia en el servidor. (El nombre de la ruta es relativo al directorio de trabajo actual, es decir, al directorio de datos del clúster). Cualquier %r se reemplaza por el nombre del archivo que contiene el último punto de reinicio válido. Ese es el archivo más antiguo que debe conservarse para permitir que la restauración sea reiniciable, por lo que esta información se puede utilizar para truncar el archivo a solo el mínimo requerido para soportar el reinicio desde la restauración actual. %r normalmente solo se utiliza en configuraciones de standby en caliente (warm standby) (consulta la Section 26.2). Escribe %% para incrustar un carácter % real.

Es importante que el comando devuelva un estado de salida cero solo si tiene éxito. Al comando se le solicitarán nombres de archivo que no están presentes en el archivo; debe devolver un valor distinto de cero cuando se le solicite. Ejemplos:

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\server\archivedir\%f" "%p"'  # Windows

Una excepción es que si el comando fue terminado por una señal (distinta de SIGTERM, que se utiliza como parte de un apagado del servidor de base de datos) o un error de la shell (como comando no encontrado), entonces la recuperación se abortará y el servidor no se iniciará.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Este parámetro opcional especifica un comando de shell que se ejecutará en cada punto de reinicio (restartpoint). El propósito de archive_cleanup_command es proporcionar un mecanismo para limpiar los archivos antiguos del WAL archivados que ya no son necesarios para el servidor en espera (standby). Cualquier %r se reemplaza por el nombre del archivo que contiene el último punto de reinicio válido. Ese es el archivo más antiguo que debe conservarse para permitir que la restauración sea reiniciable, por lo que todos los archivos anteriores a %r se pueden eliminar de forma segura. Esta información se puede utilizar para truncar el archivo a solo el mínimo requerido para soportar el reinicio desde la restauración actual. El módulo pg_archivecleanup se utiliza a menudo en archive_cleanup_command para configuraciones de un solo standby, por ejemplo:

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

Ten en cuenta, sin embargo, que si varios servidores en espera están restaurando desde el mismo directorio de archivo, deberás asegurarte de no eliminar los archivos del WAL hasta que ya no sean necesarios para ninguno de los servidores. archive_cleanup_command se utilizaría normalmente en una configuración de standby en caliente (consulta la Section 26.2). Escribe %% para incrustar un carácter % real en el comando.

Si el comando devuelve un estado de salida distinto de cero, se escribirá un mensaje de advertencia en el registro. Una excepción es que si el comando fue terminado por una señal o un error de la shell (como comando no encontrado), se producirá un error fatal.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Este parámetro especifica un comando de shell que se ejecutará una sola vez al final de la recuperación. Este parámetro es opcional. El propósito del recovery_end_command es proporcionar un mecanismo de limpieza después de la replicación o la recuperación. Cualquier %r se reemplaza por el nombre del archivo que contiene el último punto de reinicio válido, al igual que en archive_cleanup_command.

Si el comando devuelve un estado de salida distinto de cero, se escribirá un mensaje de advertencia en el registro y la base de datos procederá a iniciarse de todos modos. Una excepción es que si el comando fue terminado por una señal o un error de la shell (como comando no encontrado), la base de datos no procederá con el inicio.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Este parámetro especifica que la recuperación debe finalizar tan pronto como se alcance un estado consistente, es decir, lo antes posible. Al restaurar desde una copia de seguridad en línea, esto significa el punto donde finalizó la toma de la copia de seguridad.

Técnicamente, este es un parámetro de cadena, pero 'immediate' es actualmente el único valor permitido.

Este parámetro especifica el punto de restauración con nombre (creado con pg_create_restore_point()) al cual procederá la recuperación.

Este parámetro especifica la marca de tiempo hasta la cual procederá la recuperación. El punto de parada preciso también se ve influenciado por recovery_target_inclusive.

El valor de este parámetro es una marca de tiempo en el mismo formato aceptado por el tipo de datos timestamp with time zone, excepto que no puedes usar una abreviatura de zona horaria (a menos que la variable timezone_abbreviations se haya establecido anteriormente en el archivo de configuración). El estilo preferido es usar un desplazamiento numérico desde UTC, o puedes escribir un nombre completo de zona horaria, por ejemplo, Europe/Helsinki no EEST.

Este parámetro especifica el ID de transacción hasta el cual procederá la recuperación. Ten en cuenta que aunque los ID de transacción se asignan secuencialmente al inicio de la transacción, las transacciones pueden completarse en un orden numérico diferente. Las transacciones que se recuperarán son aquellas que se confirmaron antes de (y opcionalmente incluyendo) la especificada. El punto de parada preciso también se ve influenciado por recovery_target_inclusive.

Este parámetro especifica el LSN de la ubicación del registro de escritura anticipada hasta el cual procederá la recuperación. El punto de parada preciso también se ve influenciado por recovery_target_inclusive. Este parámetro se analiza utilizando el tipo de datos del sistema pg_lsn.

Especifica si detenerse justo después del objetivo de recuperación especificado (on), o justo antes del objetivo de recuperación (off). Se aplica cuando se especifica recovery_target_lsn, recovery_target_time o recovery_target_xid. Este ajuste controla si las transacciones que tienen exactamente la ubicación de WAL (LSN), la hora de commit o el ID de transacción de destino, respectivamente, se incluirán en la recuperación. El valor predeterminado es on.

Especifica la recuperación en una línea de tiempo (timeline) particular. El valor puede ser un ID numérico de línea de tiempo o un valor especial. El valor current realiza la recuperación a lo largo de la misma línea de tiempo que estaba activa cuando se tomó la copia de seguridad base. El valor latest realiza la recuperación hasta la última línea de tiempo encontrada en el archivo, lo cual es útil en un servidor en espera (standby). El valor predeterminado es latest.

Para especificar un ID de línea de tiempo en hexadecimal (por ejemplo, si se extrae de un nombre de archivo del WAL o de un archivo de historial), prefíjalo con un 0x. Por ejemplo, si el nombre del archivo del WAL es 00000011000000A10000004F, entonces el ID de la línea de tiempo es 0x11 (o 17 en decimal).

Normalmente solo necesitas establecer este parámetro en situaciones complejas de nueva recuperación, donde necesitas volver a un estado que a su vez se alcanzó después de una recuperación en un punto en el tiempo. Consulta la Section 25.3.6 para obtener más detalles.

Especifica qué acción debe tomar el servidor una vez que se alcanza el objetivo de recuperación. El valor predeterminado es pause, lo que significa que la recuperación se pausará. promote significa que el proceso de recuperación finalizará y el servidor comenzará a aceptar conexiones. Finalmente, shutdown detendrá el servidor después de alcanzar el objetivo de recuperación.

El uso previsto del ajuste pause es permitir la ejecución de consultas contra la base de datos para comprobar si este objetivo de recuperación es el punto más deseable para la recuperación. El estado pausado se puede reanudar utilizando pg_wal_replay_resume() (consulta la Table 9.99), lo que luego hace que finalice la recuperación. Si este objetivo de recuperación no es el punto de parada deseado, apaga el servidor, cambia las configuraciones del objetivo de recuperación a un objetivo posterior y reinicia para continuar con la recuperación.

El ajuste shutdown es útil para tener la instancia lista en el punto exacto de reproducción deseado. La instancia aún podrá reproducir más registros de WAL (y de hecho tendrá que reproducir registros de WAL desde el último checkpoint la próxima vez que se inicie).

Ten en cuenta que debido a que recovery.signal no se eliminará cuando recovery_target_action se establece en shutdown, cualquier inicio posterior finalizará con un apagado inmediato a menos que se cambie la configuración o se elimine el archivo recovery.signal manualmente.

Esta configuración no tiene efecto si no se establece ningún objetivo de recuperación. Si hot_standby no está habilitado, un ajuste de pause actuará igual que shutdown. Si se alcanza el objetivo de recuperación mientras hay una promoción en curso, un ajuste de pause actuará igual que promote.

En cualquier caso, si se configura un objetivo de recuperación pero la recuperación de archivos finaliza antes de que se alcance el objetivo, el servidor se apagará con un error fatal.

Habilita el proceso de resumen del WAL (WAL summarizer). Ten en cuenta que el resumen del WAL se puede habilitar tanto en un servidor primario como en uno en espera. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. El valor predeterminado es off.

El servidor no se puede iniciar con summarize_wal=on si wal_level está configurado en minimal. Si se configura summarize_wal=on después del inicio del servidor mientras wal_level=minimal, el summarizer se ejecutará pero se negará a generar archivos de resumen para cualquier WAL generado con wal_level=minimal.

Configura la cantidad de tiempo después de la cual el summarizer del WAL elimina automáticamente los resúmenes del WAL antiguos. La marca de tiempo del archivo se utiliza para determinar qué archivos son lo suficientemente antiguos como para eliminarse. Normalmente, deberías configurar este valor cómodamente por encima del tiempo que podría transcurrir entre una copia de seguridad y una copia de seguridad incremental posterior que dependa de ella. Los resúmenes del WAL deben estar disponibles para todo el rango de registros del WAL entre la copia de seguridad anterior y la nueva que se está tomando; si no es así, la copia de seguridad incremental fallará. Si este parámetro se establece en cero, los resúmenes del WAL no se eliminarán automáticamente, pero es seguro eliminar manualmente los archivos que sepas que no serán necesarios para futuras copias de seguridad incrementales. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. Si este valor se especifica sin unidades, se toma como minutos. El valor predeterminado es 10 días. Si summarize_wal = off, los resúmenes del WAL existentes no se eliminarán independientemente del valor de este parámetro, porque el summarizer del WAL no se ejecutará.