De duur van PostgreSQL lock-wachten beheren

Nee. FOR UPDATE vergrendelt alleen die rijen , zodat een andere transactie die ze probeert te vergrendelen (met FOR SHARE , FOR UPDATE , UPDATE of DELETE ) blokkeert totdat uw transactie wordt vastgelegd of teruggedraaid.

Als je een hele tafelvergrendeling wilt die invoegingen/updates/verwijderingen blokkeert, wil je waarschijnlijk LOCK TABLE ... IN EXCLUSIVE MODE .

1. Zie de lock_timeout instelling . Dit is toegevoegd in 9.3 en is niet beschikbaar in oudere versies.

   Ruwe benaderingen voor oudere versies kunnen worden bereikt met statement_timeout , maar dat kan ertoe leiden dat verklaringen onnodig worden geannuleerd. Als statement_timeout is 1s en een instructie wacht 950 ms op een vergrendeling, het kan dan de vergrendeling krijgen en doorgaan, alleen om onmiddellijk te worden geannuleerd door een time-out. Niet wat je wilt.

   Er is geen manier om op queryniveau lock_timeout in te stellen , maar u kunt en moet gewoon:

   SET LOCAL lock_timeout = '1s';

   nadat je BEGIN een transactie.

2. Er is een statement time-out, maar vergrendelingen worden vastgehouden bij transactie niveau. Er is geen time-outfunctie voor transacties.

   Als u transacties op één afschrift uitvoert, kunt u gewoon een statement_timeout . instellen voordat u de instructie uitvoert om te beperken hoe lang deze kan worden uitgevoerd. Dit is echter niet hetzelfde als het beperken van hoe lang het een slot kan vasthouden, omdat het 900 ms van een toegestane 1s voor het slot kan wachten, het slot slechts 100 ms vasthoudt en vervolgens wordt geannuleerd tegen de time-out.

3. Nee. U moet:

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

4. SET LOCAL is hiervoor geschikt en heeft de voorkeur.

   Er is geen manier om dit in de tekst van de query te doen, het moet een afzonderlijke verklaring zijn.

   Het mailinglijstbericht waarnaar u linkt, is een voorstel voor een denkbeeldige syntaxis die nooit is geïmplementeerd (tenminste in een openbare PostgreSQL-release) en niet bestaat.

In een situatie als deze wilt u misschien "optimistische gelijktijdigheidscontrole" overwegen, vaak "optimistische vergrendeling" genoemd. Het geeft u meer controle over het vergrendelingsgedrag ten koste van een hogere frequentie van herhaalde zoekopdrachten en de behoefte aan meer toepassingslogica.