Equivalente de PostgreSQL de SQLServer NoLock Sugerencia

En SQLServer, puede utilizar la sintaxis "(nolock)" para garantizar que la consulta no bloquee la tabla o que no esté bloqueada por otras consultas que bloqueen la misma tabla. p.Equivalente de PostgreSQL de SQLServer NoLock Sugerencia

SELECT * FROM mytable (nolock) WHERE id = blah

¿Cuál es la sintaxis equivalente en Postgres? Encontré algo de documentación sobre bloqueo de tablas en PG (http://www.postgresql.org/docs/8.1/interactive/sql-lock.html), pero todo parece orientado a cómo bloquear una tabla, no asegurarse de que no está bloqueado.

Fuente

2010-03-06 Cerin

Espera, a ver si lo entiendo. ¿Hay una opción para IGNORAR los bloqueos en una mesa? Si es cierto, esa es una mala idea que se clasifica con la opción de ignorar filas existentes al validar nuevas restricciones. –

@Matthew Wood: En general, yo tendería a estar de acuerdo. Sin embargo, ignorar bloqueos es útil para ciertos casos, como la depuración cuando se desea inspeccionar el contenido de una tabla, aunque se encuentre en medio de una actualización muy grande. Ignorar el bloqueo es preferible esperar varios minutos/horas para que se complete la actualización. – Cerin

Un SELECT no se bloquea cualquier tabla en PostgreSQL, a menos que desee una cerradura:

SELECT * FROM tablename FOR UPDATE;

PostgreSQL usa MVCC para minimizar la contención de bloqueo con el fin de permitir un rendimiento razonable en entornos multiusuario. Los lectores no entran en conflicto con escritores ni otros lectores.

Fuente

2010-03-07 00:13:12

He investigado un poco y parece que la sugerencia de NOLOCK en SQL Server es más o menos la misma que en el nivel de aislamiento de transacción LEÍDO INCOMPARTIDO. En PostgreSQL, puede configurar READ UNCOMMITTED, pero actualiza silenciosamente el nivel para LEER COMPROMETIDO. LEER SIN COMPROMISO no es compatible.

PostgreSQL 8.4 documentación para el aislamiento de la transacción: http://www.postgresql.org/docs/8.4/static/transaction-iso.html

Fuente

2010-03-07 17:33:22

Una pequeña cita para resaltar la causa de esto: _La razón por la que PostgreSQL solo proporciona dos niveles de aislamiento es que esta es la única forma sensata de asignar los niveles de aislamiento estándar a la arquitectura de control de concurrencia multiversion. – dezso

@dezso: +1, pero en 9.1 se agregó SERIALIZABLE, por lo que los documentos se han actualizado para decir "... proporciona tres niveles de aislamiento ..." pero es lo mismo. –

Equivalente de PostgreSQL de SQLServer NoLock Sugerencia

Respuesta

Cuestiones relacionadas