Controlar la duración de las esperas de bloqueo de PostgreSQL

No. FOR UPDATE bloquea solo esas filas , para que otra transacción que intente bloquearlos (con FOR SHARE , FOR UPDATE , UPDATE o DELETE ) bloquea hasta que su transacción se confirme o revierta.

Si desea un bloqueo de tabla completo que bloquee las inserciones/actualizaciones/eliminaciones, probablemente desee LOCK TABLE ... IN EXCLUSIVE MODE .

1. Consulte el lock_timeout ajuste . Esto se agregó en 9.3 y no está disponible en versiones anteriores.

   Se pueden lograr aproximaciones crudas para versiones anteriores con statement_timeout , pero eso puede llevar a que las declaraciones se cancelen innecesariamente. Si statement_timeout es 1 s y una declaración espera 950 ms en un bloqueo, luego puede obtener el bloqueo y continuar, solo para ser cancelado inmediatamente por un tiempo de espera. No es lo que quieres.

   No hay una forma de nivel de consulta para configurar lock_timeout , pero usted puede y debería simplemente:

   SET LOCAL lock_timeout = '1s';

   después de BEGIN una transacción.

2. Hay una declaración tiempo de espera, pero los bloqueos se mantienen en transacción nivel. No hay función de tiempo de espera de transacción.

   Si está ejecutando transacciones de un solo extracto, puede configurar un statement_timeout antes de ejecutar la declaración para limitar el tiempo durante el cual puede ejecutarse. Sin embargo, esto no es lo mismo que limitar el tiempo que puede mantener un bloqueo, ya que puede esperar 900 ms de un 1 permitido para el bloqueo, solo mantener el bloqueo durante 100 ms y luego cancelarse por el tiempo de espera.

3. No. Debes:

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

4. SET LOCAL es adecuado y preferido para esto.

   No hay forma de hacerlo en el texto de la consulta, debe ser una declaración separada.

   La publicación de la lista de correo a la que se vinculó es una propuesta para una sintaxis imaginaria que nunca se implementó (al menos en una versión pública de PostgreSQL) y no existe.

En una situación como esta, es posible que desee considerar el "control de concurrencia optimista", a menudo llamado "bloqueo optimista". Le brinda un mayor control sobre el comportamiento de bloqueo a costa de mayores tasas de repetición de consultas y la necesidad de más lógica de aplicación.