Controllo della durata delle attese di blocco di PostgreSQL

No. FOR UPDATE blocca solo quelle righe , in modo che un'altra transazione che tenti di bloccarli (con FOR SHARE , FOR UPDATE , UPDATE o DELETE ) si blocca fino al commit o al rollback della transazione.

Se vuoi un blocco dell'intera tabella che blocchi inserimenti/aggiornamenti/cancellazioni probabilmente vuoi LOCK TABLE ... IN EXCLUSIVE MODE .

1. Vedi il lock_timeout impostazione . Questo è stato aggiunto in 9.3 e non è disponibile nelle versioni precedenti.

   È possibile ottenere approssimazioni grezze per le versioni precedenti con statement_timeout , ma ciò può comportare l'annullamento non necessario delle dichiarazioni. Se statement_timeout è 1s e un'istruzione attende 950 ms su un blocco, potrebbe quindi ottenere il blocco e procedere, solo per essere immediatamente annullata da un timeout. Non è quello che vuoi.

   Non esiste un modo a livello di query per impostare lock_timeout , ma tu puoi e dovrebbe solo:

   SET LOCAL lock_timeout = '1s';

   dopo aver BEGIN una transazione.

2. C'è una dichiarazione timeout, ma i blocchi vengono mantenuti durante la transazione livello. Non è presente alcuna funzione di timeout delle transazioni.

   Se stai eseguendo transazioni con istruzione singola, puoi semplicemente impostare un statement_timeout prima di eseguire l'istruzione per limitare il tempo di esecuzione. Questo non è esattamente la stessa cosa che limitare la durata di un blocco, tuttavia, perché potrebbe attendere 900 ms di 1 secondo consentito per il blocco, in realtà mantenere il blocco solo per 100 ms, quindi essere annullato entro il timeout.

3. No. Devi:

   BEGIN;
   SET LOCAL lock_timeout = '4s';
   SELECT ....;
   COMMIT;
   

4. SET LOCAL è adatto e preferito per questo.

   Non c'è modo di farlo nel testo della query, deve essere un'istruzione separata.

   Il post della mailing list a cui ti sei collegato è una proposta per una sintassi immaginaria che non è mai stata implementata (almeno in una versione pubblica di PostgreSQL) e non esiste.

In una situazione come questa potresti prendere in considerazione il "controllo ottimistico della concorrenza", spesso chiamato "blocco ottimistico". Ti offre un maggiore controllo sul comportamento di blocco a scapito di un aumento dei tassi di ripetizione delle query e della necessità di una maggiore logica dell'applicazione.