Incoerenza nella lettura ripetibile

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

La modalità di lettura ripetibile fornisce una rigorosa garanzia che ogni transazione abbia una visione completamente stabile del database. Tuttavia, questa visione non sarà necessariamente sempre coerente con alcune esecuzioni seriali (una alla volta) di transazioni simultanee dello stesso livello. Ad esempio, anche una transazione di sola lettura a questo livello potrebbe visualizzare un record di controllo aggiornato per mostrare che un batch è stato completato ma non vedere uno dei record di dettaglio che è logicamente parte del batch perché legge una revisione precedente del record di controllo . È improbabile che i tentativi di applicare le regole aziendali mediante transazioni in esecuzione a questo livello di isolamento funzionino correttamente senza un uso attento dei blocchi espliciti per bloccare le transazioni in conflitto.

Non è una lettura fantasma, cosa impossibile in modalità di lettura ripetibile?

La documentazione afferma che una query in una transazione di lettura ripetibile vede un'istantanea all'inizio della transazione, quindi come potrebbe essere possibile per una query leggere dati incoerenti?

Ecco la mia lettura di quella sezione. Devo ammettere che è confuso.

Supponiamo che io abbia due tabelle:

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)
);

Supponiamo ora di inserire record batch e dettagli in diverse transazioni. La sessione 1 inserisce un batch e inizia a inserire i dettagli ma prima che termini, si avvia la sessione 2. La sessione 2 visualizza le informazioni sull'intestazione del batch, ma non attende i dettagli del commit per informare l'utente che non sono stati trovati record. Ora se il batch e i dettagli sono interamente nella stessa transazione, questo non è mai un problema.

ciò differirebbe dalla serializzazione in cui ci si aspetterebbe che il completamento dell'inserimento precedente, il commit o il rollback prima di determinare se notificare all'utente che non sono state trovate righe.

C'è un documento nel Wiki PostgreSQL che mostra alcuni problemi che possono verificarsi con determinate combinazioni di transazioni a livello di isolamento delle transazioni REPEATABLE READ e come sono evitati a livello di isolamento delle transazioni SERIALIZZABILE a partire da PostgreSQL versione 9.1.

Include anche un esempio di come potrebbe essere possibile per una transazione READ-SOLO READATABLE di livello READ-ON di leggere dati incoerenti.

Le letture fantasma (assicurarsi di non confonderlo con letture non ripetibili) sono possibili nel livello di isolamento "Lettura ripetibile" ... in linea di principio. Ma il comportamento di fatto di Postgresql quando si seleziona "Lettura ripetibile" è più forte dello standard (quasi un isolamento "serializzabile"), quindi, in effetti, non si avranno letture fantasma. Documenti :

Quando si seleziona il livello Leggi non confermato, si ottiene davvero il commit della lettura e le letture fantasma non sono possibili nell'implementazione PostgreSQL della lettura ripetibile , quindi il livello di isolamento effettivo potrebbe essere più rigoroso di quello selezionato.

Ora, che dire di questo avvertimento "questa visione non sarà necessariamente sempre coerente con l'esecuzione seriale (una alla volta) di transazioni simultanee dello stesso livello"? Penso (non ne sono sicuro) che significhi che lo snapshot "dall'esterno" (risolto all'inizio della transazione) può eventualmente includere righe di altre transazioni ma non includere alcune altre righe di quella stessa transazione.