Inconsistencia en lectura repetible

http://www.postgresql.org/docs/9.2/static/transaction-iso.html

El modo de lectura repetible proporciona una garantía rigurosa de que cada transacción ve una vista completamente estable de la base de datos. Sin embargo, esta vista no siempre será coherente con alguna ejecución en serie (una a la vez) de transacciones concurrentes del mismo nivel. Por ejemplo, incluso una transacción de solo lectura en este nivel puede ver un registro de control actualizado para mostrar que se ha completado un lote, pero no ver uno de los registros detallados que es lógicamente parte del lote porque lee una revisión anterior del registro de control . No es probable que los intentos de imponer reglas comerciales mediante transacciones que se ejecutan en este nivel de aislamiento funcionen correctamente sin el uso cuidadoso de bloqueos explícitos para bloquear transacciones conflictivas.

¿No es una lectura fantasma, que no es posible en modo de lectura repetible?

La documentación dice que una consulta en una transacción de lectura repetible ve una instantánea al comienzo de la transacción, entonces, ¿cómo podría ser posible que una consulta lea datos inconsistentes?

Aquí está mi lectura de esa sección. Admitiré que es confuso.

Supongamos que tengo dos tablas:

CREATE TABLE batch (
   id serial not null unique,
   control_code text primary key,
   date_posted date not null default now()
);

CREATE TABLE details (
   batch_id int not null references batch(id),
   description text,
   primary key(batch_id, description)
);

Ahora, supongamos que insertamos registros de lotes y detalles en diferentes transacciones. La sesión 1 inserta un lote y comienza a insertar detalles, pero antes de que finalice, se inicia la sesión 2. La sesión 2 puede ver la información del encabezado del lote, pero no espera los detalles de confirmación para informar al usuario que no se encuentran registros. Ahora, si su lote y detalles están completamente en la misma transacción, esto nunca es un problema.

esto sería diferente de serializable donde esperaría esperar a que se complete la inserción anterior y se confirme o revierta antes de determinar si se debe notificar al usuario que no se encontraron filas.

Hay un documento en el Wiki de PostgreSQL que muestra algunos problemas que pueden ocurrir con ciertas combinaciones de transacciones en el nivel de aislamiento de transacciones REPEATABLE READ, y cómo se evitan en el nivel de aislamiento de transacciones SERIALIZABLE que comienza con PostgreSQL versión 9.1.

También incluye un ejemplo de cómo podría ser posible que una transacción READATABLE READ-level READ-ONLY lea datos inconsistentes.

Las lecturas fantasmas (asegúrese de no confundir esto con lecturas no repetibles) son posibles en el nivel de aislamiento "Lectura repetible" ... en principio. Pero el comportamiento de facto de Postgresql cuando selecciona "Lectura repetible" es más fuerte que el estándar (casi un aislamiento "serializable"), de modo que, de hecho, no tendrá lecturas fantasma. Documentos :

Cuando selecciona el nivel Lectura no confirmada, realmente obtiene Lectura confirmada, y las lecturas fantasmas no son posibles en la implementación de PostgreSQL de Lectura repetible , por lo que el nivel de aislamiento real puede ser más estricto de lo que selecciona.

Ahora, ¿qué pasa con esa advertencia "esta opinión no siempre será coherente con alguna ejecución en serie (una a la vez) de transacciones concurrentes del mismo nivel"? Creo (no estoy seguro) que eso significa que la instantánea "desde el exterior" (fijada al comienzo de la transacción) puede eventualmente incluir filas de otras transacciones, pero no puede incluir algunas otras filas de la misma transacción.