Invalidación de caché consciente de las transacciones en PostgreSQL
Esta guía explica cómo los triggers de las tablas adjuntas impiden que un acierto RESP obsoleto siga a una escritura confirmada en PostgreSQL.
Un trigger registra las claves modificadas o una relación modificada dentro de la transacción de escritura. Al confirmar, la extensión publica barreras de invalidación e incrementa las generaciones. Una carga que empezó antes de la barrera no puede publicar datos obsoletos. Un rollback antes de publicar la barrera descarta el estado modificado de la transacción y mantiene válidas las entradas anteriores. Si la transacción se aborta después de publicar la barrera, la invalidación no se revierte y las entradas afectadas siguen siendo inválidas.
Consulte la referencia técnica de coherencia para conocer el contrato completo de la ruta de lectura.
Comprobar la invalidación entre SQL y RESP
Inicie la demostración local y lea la misma clave desde RESP y PostgreSQL:
MGET CRUD:pglc_demo.public.items:{"id":42}
En otra sesión SQL, actualice y confirme:
BEGIN;
UPDATE public.items SET revision = revision + 1 WHERE id = 42;
COMMIT;
El siguiente comando RESP devuelve la revisión confirmada. Si el escritor revierte la transacción, RESP sigue devolviendo la última revisión confirmada.
RESP usa el rol de PostgreSQL configurado en una transacción breve e independiente. No comparte el rol, la transacción ni la instantánea de la aplicación. Para leer las escrituras propias y usar SELECT ... FOR UPDATE, ejecute SQL en la transacción de la aplicación.
Casos que omiten la caché deliberadamente
Con pg_local_cache.enabled desactivado, RESP MGET omite la consulta y la carga de caché y lee la tabla de origen. Una barrera de escritura activa para una clave, una relación o de forma global también bloquea las lecturas desde caché y las nuevas cargas, por lo que se lee la tabla de origen. Los workers RESP se inician después de que termina la recuperación; esta no es una condición independiente para omitir la caché. Una fila que no cabe en una entrada puede devolverse desde PostgreSQL si su JSON cabe en el límite de valor RESP, pero no se almacena.
Inspeccionar la causa de un fallo de caché
Compare local_cache.stats() y local_cache.health() antes y después de una carga de trabajo controlada. Revise los contadores de bypass, fallos de caché, invalidaciones y recarga de asignaciones. Consulte la lista técnica de métricas.
Actualizado .