Una query INSERT-SELECT può essere soggetta a condizioni di competizione?

Question

Ho questa query che tenta di aggiungere righe alla tabella balances se non esiste una riga corrispondente nella tabella totals. La query viene eseguita in una transazione utilizzando il livello di isolamento predefinito su PostgreSQL.

INSERT INTO balances (account_id, currency, amount) 
SELECT t.account_id, t.currency, 0 
FROM balances AS b 
RIGHT OUTER JOIN totals USING (account_id, currency) AS t 
WHERE b.id IS NULL 

Ho un vincolo UNIQUE su balances (accountId, currency). Sono preoccupato che entrerò in una situazione di condizione di competizione che porterà a duplicare gli errori delle chiavi se più sessioni eseguono questa query contemporaneamente. Ho visto molte domande su questo argomento, ma sembrano coinvolgere sia sottoquery, più query o funzioni pgSQL.

Poiché non sto utilizzando nessuno di quelli nella mia domanda, è libero da condizioni di gara? Se non è come posso ripararlo?

Answer 1

Si verrà a mancare con un errore duplicate key value violates unique constraint . Quello che faccio è inserire il codice di inserimento in un blocco try/except e quando viene lanciata l'eccezione, lo prendo e riprovo. Così semplice A meno che l'applicazione abbia una quantità enorme di utenti, funzionerà perfettamente.

Nella query è sufficiente il livello di isolamento predefinito poiché si tratta di una singola istruzione di inserimento e non vi è alcun rischio di letture fantasma.

Si noti che anche quando si imposta il livello di isolamento su serializzabile, il blocco try/except non è evitabile. From the manual about serializable:

come il livello Repeatable Read, le applicazioni che utilizzano questo livello deve essere preparato per riprovare le operazioni a causa di errori di serializzazione

Answer 2

Il livello di transazione predefinito è Read Committed. Le letture fantasma sono possibili in questo livello (vedi Table 13.1). Mentre sei protetto dal vedere gli effetti strani nella tabella dei totali se dovessi aggiornare i totali, non sei protetto dalle letture fantasma nella tabella dei saldi.

Ciò significa che può essere spiegato quando si esamina una singola query simile alla propria che tenta il join esterno due volte (e solo le query, non inserisce nulla). Il fatto che manchi un bilanciamento non è garantito che rimanga lo stesso tra le due "sbirciatine" nella tabella delle bilance. L'improvvisa apparizione di un equilibrio che non era presente quando la stessa transazione è stata esaminata per la prima volta, viene definita "lettura fantasma".

Nel vostro caso, diverse istruzioni concorrenti possono vedere che manca un bilanciamento e nulla impedisce loro di provare ad inserirlo e ad uscire.

per escludere letture fantasma (e per fissare la query), è necessario eseguire nel nel livello di isolamento SERIALIZABLE prima di eseguire la query:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE