TOAST fue introducido en PostgreSQL para manejar datos de fila que exceden el tamaño de página de 8KB comprimiendo grandes columnas en un almacenamiento físico separado. Cuando la replicación lógica transmite cambios a través del WAL, la configuración de REPLICA IDENTITY determina qué valores antiguos de tupla se incluyen. La configuración predeterminada REPLICA IDENTITY DEFAULT envía solo la clave primaria, mientras que REPLICA IDENTITY FULL envía la imagen completa de la fila antigua.
Cuando una tabla contiene columnas JSONB o TEXT que exceden ~2KB y se comprimen en TOAST, las operaciones de UPDATE que modifican solo columnas no TOAST pueden no obtener los valores TOAST externos para el registro WAL. El proceso de decodificación lógica omite los punteros TOAST sin cambios para reducir I/O, lo que hace que el suscriptor reciba valores NULL o faltantes para estos campos grandes durante la resolución de conflictos.
Cambiar a REPLICA IDENTITY FULL obliga a PostgreSQL a incluir la tupla antigua completa en el registro WAL, obteniendo explícitamente todos los valores TOAST de almacenamiento externo durante la confirmación. Aunque esto garantiza la integridad de los datos para operaciones UPSERT, aumenta significativamente el volumen del WAL—a menudo entre 300-500% para tablas JSONB amplias—porque cada UPDATE debe registrar la imagen completa previa de la fila.
Una plataforma de comercio financiero necesitaba replicar instantáneas del libro de órdenes de un clúster primario de PostgreSQL 15 a un almacén de datos para informes regulatorios. La tabla market_data almacenaba identificadores de instrumentos y grandes cargas JSONB (10-50KB) que contenían información de la profundidad del libro. La replicación utilizó pglogical con REPLICA IDENTITY DEFAULT (solo clave primaria). El proceso ETL en el lado del almacén intentó realizar operaciones UPSERT para mantener una tabla de dimensión de cambio lento, requiriendo los antiguos valores JSONB para calcular los cambios delta para el registro de auditoría.
Durante períodos de trading de alto volumen, cuando el libro de órdenes se actualizaba con frecuencia, pero la carga JSONB permanecía sin cambios, el flujo de replicación lógica enviaba registros UPDATE que contenían solo la clave primaria y los nuevos datos de tupla. Los valores antiguos TOASTed JSONB no se incluyeron en el conjunto de cambios porque la instrucción UPDATE solo tocaba la columna de marca de tiempo updated_at. El proceso ETL no pudo acceder al estado anterior de JSONB, lo que hizo imposible calcular deltas de movimiento de precios precisos para la auditoría, violando los requisitos de cumplimiento de MiFID II.
Solución 1: Cambiar a REPLICA IDENTITY FULL Este enfoque obligaría al publicador a escribir la imagen completa de la fila antigua en el WAL para cada UPDATE, incluyendo todo el contenido JSONB del almacenamiento TOAST. Los pros incluían la garantía de integridad de datos y una implementación simple que no requería cambios en el esquema. Sin embargo, los contras eran significativos: la generación de WAL aumentaría aproximadamente un 400% dados los 50KB de cargas, arriesgando el agotamiento del espacio en disco en el primario y aumentando la latencia de la red hacia el almacén. Para una tabla que procesa 10,000 actualizaciones por segundo, esto se consideró demasiado arriesgado para la estabilidad de producción.
Solución 2: Registro a nivel de aplicación con una tabla de historial separada
El equipo consideró crear un trigger en el primario que copiara los antiguos valores JSONB en una tabla market_data_history separada antes de la actualización. Los pros eran que la replicación lógica podría replicar esta tabla de historial por separado, evitando el problema de omisión TOAST en la tabla principal mientras mantenía pequeño el pie de WAL de la tabla principal. Los contras incluían una sobrecarga de escritura doble en el primario (aumentando la latencia de la transacción), requisitos de almacenamiento adicionales que crecían al 2x, y complejidad en la lógica ETL para correlacionar registros de historial con cambios en la tabla principal usando IDs de transacción y marcas de tiempo.
Solución 3: Usar REPLICA IDENTITY con un índice cubriente incluyendo un hash del JSONB
Esta estrategia implicaba crear un índice funcional sobre md5(jsonb_column::text) e incluir ese hash en un índice REPLICA IDENTITY compuesto. Los pros eran que los cambios en el contenido JSONB serían detectables a través del cambio de hash en el WAL sin enviar toda la carga. Los contras incluían la incapacidad de recuperar el valor antiguo real (solo su hash), lo que era insuficiente para el requisito normativo de mostrar el estado exacto anterior a la actualización, y la sobrecarga de mantenimiento del índice sobre tablas de alta rotación.
El equipo seleccionó Solución 2 (Registro a nivel de aplicación) pero con una modificación. Utilizaron la optimización de actualización parcial de JSONB de PostgreSQL disponible en la versión 14+ e implementaron un trigger BEFORE UPDATE que almacenaba solo las rutas modificadas (diff) en lugar de la fila antigua completa. Esto redujo el crecimiento de la tabla de historial mientras aseguraba que todos los datos de pre-imagen necesarios estuvieran disponibles. Mantuvieron REPLICA IDENTITY DEFAULT en la tabla principal para evitar el crecimiento de WAL, dirigiendo el ETL a unirse con la tabla de historial para la reconstrucción de auditoría.
El tamaño del flujo de replicación permaneció estable, previniendo presión sobre el almacenamiento primario. El proceso ETL reconstruyó exitosamente pistas de auditoría completas al combinar el estado actual de la fila con los diffs almacenados de la tabla de historial. Se logró el cumplimiento regulatorio con solo un aumento del 15% en el almacenamiento primario (en comparación con el 400% para REPLICA IDENTITY FULL) y un impacto mínimo en el rendimiento de transacciones.
¿Por qué la decodificación lógica de PostgreSQL omite valores TOAST incluso cuando la columna se modifica?
Muchos candidatos suponen que cualquier UPDATE automáticamente obtiene todos los valores TOASTed para el WAL. Sin embargo, PostgreSQL solo realiza "unTOASTing de tuplas" cuando el ejecutor realmente lee el dato para modificarlo. Si un UPDATE modifica una columna diferente (por ejemplo, SET updated_at = NOW()) sin hacer referencia a la columna JSONB en su lista de objetivos o cláusula WHERE, el puntero TOAST permanece sin cambios y el almacenamiento externo no se accede. Por lo tanto, el registro WAL contiene solo la tupla en disco con su puntero, no los datos reales. Dado que la decodificación lógica reconstruye tuplas a partir del WAL sin acceder a las tablas de montículo o TOAST para versiones antiguas, el valor omitido aparece como NULL en el flujo de cambios.
¿Cómo interactúa REPLICA IDENTITY FULL con las actualizaciones HOT (Heap-Only Tuple)?
Los candidatos a menudo pasan por alto que REPLICA IDENTITY FULL desactiva las actualizaciones HOT para una tabla. Las actualizaciones HOT permiten a PostgreSQL encadenar versiones de fila dentro de la misma página de datos sin actualizar cada entrada de índice, siempre que ninguna columna indexada cambie. Cuando REPLICA IDENTITY FULL está activo, cada UPDATE debe registrar la imagen completa de la fila antigua para la replicación, lo que requiere que el sistema identifique la fila de manera única por su contenido completo. Esto rompe la optimización HOT porque la replicación lógica necesita información completa de comparación de tuplas, forzando actualizaciones de índice para cada versión de fila incluso cuando se modifican columnas no indexadas. En consecuencia, las tablas con esta configuración experimentan mayor hinchazón de índice y un aumento en I/O, un compromiso crítico para tablas de alta rotación.
¿Cuál es la diferencia entre la compresión TOAST y la compresión WAL de PostgreSQL, y cómo interactúan durante la replicación lógica?
Esta pregunta separa el conocimiento profundo del sistema de la comprensión superficial. La compresión TOAST reduce el tamaño de la fila utilizando LZ4 o PGLZ antes de almacenar grandes columnas en tablas externas. La compresión WAL (habilitada a través de wal_compression=lz4) comprime imágenes de página completas escritas en el WAL para la eficiencia de recuperación ante fallos. Sin embargo, cuando se utiliza REPLICA IDENTITY FULL, los datos antiguos de tupla enviados a la decodificación lógica se extraen antes de que el registro WAL sea comprimido para almacenamiento. Por lo tanto, el decodificador lógico recibe datos TOAST descomprimidos (si se obtienen), mientras que el archivo WAL físico podría almacenarlo comprimido si forma parte de una imagen de página completa, afectando el ancho de banda de la red frente a I/O de disco de manera diferente.