PostgreSQL
Write-Ahead Logging, checkpoints, fsync y recuperación tras fallos para entender cómo PostgreSQL hace durables los cambios antes de escribir páginas de datos.
WAL no es un backup ni una copia legible de las tablas. Es el registro ordenado que permite confirmar transacciones antes de escribir todas las páginas de datos, recuperarse de un crash, alimentar réplicas y reproducir cambios hasta un punto concreto.
Write-Ahead Logging impone una regla:
el registro WAL que describe un cambio
→ debe quedar seguro antes
→ que la página de datos modificada pueda considerarse persistidaLa aplicación modifica filas; PostgreSQL cambia páginas en memoria y genera registros WAL. En el commit, lo importante para durabilidad es que el WAL necesario alcance el nivel de persistencia configurado. Las páginas heap e índice pueden escribirse después.
Escribir todas las páginas modificadas en cada commit sería costoso y produciría muchas escrituras aleatorias. WAL convierte el camino crítico en una secuencia principalmente append-only:
UPDATE
→ cambia buffers
→ genera WAL
→ flush del WAL
→ COMMIT responde
→ páginas sucias se escriben más tardeSi el servidor cae, el recovery vuelve a aplicar registros WAL desde el último checkpoint para llevar los archivos a un estado consistente.
Cada posición del WAL tiene un Log Sequence Number. Sirve para expresar:
El WAL se almacena en archivos segmentados dentro de pg_wal. No deben eliminarse manualmente: su retención depende de recovery, archiving, replicas y replication slots.
1. La transacción modifica buffers.
2. PostgreSQL genera records WAL.
3. Se escribe el commit record.
4. WAL se flush según synchronous_commit y fsync.
5. El cliente recibe confirmación.
6. Checkpointer/background writer escriben data pages después.Una respuesta exitosa significa que se cumplieron las garantías configuradas, no que cada archivo de tabla ya fue escrito.
Un checkpoint establece un punto desde el cual comenzar recovery y coordina la escritura de páginas sucias anteriores.
Trade-off:
checkpoints frecuentes
→ recovery potencialmente corto
→ más picos de I/O y full-page images
checkpoints espaciados
→ escritura más distribuida
→ más WAL y recovery potencialmente largoParámetros como checkpoint_timeout, max_wal_size y checkpoint_completion_target interactúan. No se ajustan aislados: observa logs, volumen de WAL, latencia y storage.
La primera modificación de una página después de un checkpoint puede incluir una imagen completa en WAL. Esto protege frente a torn pages, donde una escritura física incompleta deja una página parcialmente actualizada.
Consecuencias:
full_page_writes sin una garantía equivalente del storage es peligroso.fsync=on pide al sistema operativo que los datos críticos lleguen a almacenamiento durable.
Desactivarlo puede mejorar benchmarks, pero tras crash puede producir corrupción, no solo pérdida de las últimas transacciones. Solo tiene sentido en clusters desechables y reconstruibles.
Controla cuándo una transacción considera suficiente el WAL para responder.
Con valores que permiten commit asíncrono, el cliente puede recibir éxito antes de que el commit record esté durable localmente. Un crash inmediato podría perder transacciones recientes aunque la base permanezca consistente.
Esto puede servir para eventos reconstruibles o telemetría, no para datos cuya confirmación debe ser fuerte. Puede configurarse por transacción:
SET LOCAL synchronous_commit = off;La decisión es de negocio y operación, no un “tuning gratis”.
Con standbys síncronos, el commit puede esperar que una réplica reciba, escriba, haga flush o reproduzca WAL según synchronous_commit y configuración.
Beneficio:
Coste:
Para PITR, los segmentos completos deben archivarse fuera de pg_wal:
base backup
+ WAL archivado continuo
→ restauración hasta un instante/LSN/transacciónarchive_command o mecanismos equivalentes deben ser:
Si el archiving falla y WAL no puede reciclarse, pg_wal crece hasta llenar disco.
Un slot conserva WAL necesario para un consumidor.
Ventaja:
Riesgo:
Monitorea:
restart_lsn.confirmed_flush_lsn en logical slots.WAL depende de una base física coherente. Sin base backup o backup lógico adecuado, una colección de segmentos no basta para reconstruir arbitrariamente el cluster.
Además, un DROP TABLE confirmado también queda registrado: recovery normal reproduce la eliminación. Para volver a antes del error necesitas restore/PITR, no “leer el WAL y deshacer”.
Al iniciar después de una caída no limpia:
Recovery puede tardar según cantidad de WAL, velocidad de storage y configuración.
CREATE UNLOGGED TABLE staging_import (...);Reducen WAL de datos y pueden acelerar cargas, pero:
Los cambios de catálogo y ciertos efectos aún generan WAL.
Operaciones masivas producen:
Antes de un backfill:
estima filas × ancho × índices
→ observa WAL por lote
→ limita transaction size
→ monitorea replicas y discoFuentes útiles:
SELECT pg_current_wal_lsn();
SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)
FROM pg_stat_replication;También revisa:
pg_stat_wal según versión.pg_stat_archiver.pg_wal.WAL local durable no protege contra pérdida total del disco o región. Necesitas replicas/backups.
El resultado puede ser incierto: la transacción quizá confirmó. Usa idempotency keys y reconciliación.
PostgreSQL recicla el segmento y el PITR queda roto. Verifica integridad externa.
El slot puede llenar el disco del primary.
Un workload masivo supera max_wal_size y fuerza checkpoints frecuentes, aumentando WAL e I/O.
pg_wal para liberar espacio.synchronous_commit=off sin clasificar datos.synchronous_commit=off?pg_wal.JSON, JSONB y modelado híbrido decide cuándo una estructura flexible complementa al modelo relacional sin reemplazar integridad.