PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Steuern der Dauer von PostgreSQL-Sperrwartezeiten

Nö. FOR UPDATE sperrt nur diese Zeilen , sodass eine andere Transaktion, die versucht, sie zu sperren (mit FOR SHARE , FOR UPDATE , UPDATE oder DELETE ) blockiert, bis Ihre Transaktion festgeschrieben oder zurückgesetzt wird.

Wenn Sie eine ganze Tabellensperre wollen, die Einfügungen/Aktualisierungen/Löschungen blockiert, möchten Sie wahrscheinlich LOCK TABLE ... IN EXCLUSIVE MODE .

  1. Siehe den lock_timeout Einstellung . Dies wurde in 9.3 hinzugefügt und ist in älteren Versionen nicht verfügbar.

    Grobe Annäherungen für ältere Versionen können mit statement_timeout erreicht werden , was aber dazu führen kann, dass Auszüge unnötig abgebrochen werden. Wenn statement_timeout 1s ist und eine Anweisung 950 ms auf eine Sperre wartet, kann sie dann die Sperre erhalten und fortfahren, nur um sofort durch eine Zeitüberschreitung abgebrochen zu werden. Nicht das, was Sie wollen.

    Es gibt keine Möglichkeit, lock_timeout auf Abfrageebene festzulegen , aber Sie können und sollte nur:

    SET LOCAL lock_timeout = '1s';

    nachdem Sie BEGIN eine Transaktion.

  2. Es gibt eine Anweisung Timeout, aber Sperren werden bei Transaktion gehalten eben. Es gibt keine Transaktions-Timeout-Funktion.

    Wenn Sie Transaktionen mit einer einzigen Anweisung ausführen, können Sie einfach ein statement_timeout festlegen bevor Sie die Anweisung ausführen, um zu begrenzen, wie lange sie ausgeführt werden kann. Dies ist jedoch nicht ganz dasselbe wie die Begrenzung, wie lange eine Sperre gehalten werden kann, da möglicherweise 900 ms von zulässigen 1 s auf die Sperre gewartet werden, die Sperre tatsächlich nur 100 ms gehalten wird und dann durch das Timeout abgebrochen wird. P>

  3. Nein. Sie müssen:

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

  4. SET LOCAL ist hierfür geeignet und bevorzugt.

    Es gibt keine Möglichkeit, dies im Text der Abfrage zu tun, es muss eine separate Anweisung sein.

    Der Mailinglistenbeitrag, auf den Sie verlinkt haben, ist ein Vorschlag für eine imaginäre Syntax, die nie implementiert wurde (zumindest in einer öffentlichen PostgreSQL-Version) und nicht existiert.

In einer solchen Situation sollten Sie eine "optimistische Parallelitätssteuerung" in Betracht ziehen, die oft als "optimistisches Sperren" bezeichnet wird. Es gibt Ihnen eine bessere Kontrolle über das Sperrverhalten auf Kosten höherer Abfragewiederholungsraten und des Bedarfs an mehr Anwendungslogik.