Posterior a de una larga selección de información solucionamos esta interrogante que suelen tener muchos de nuestros usuarios. Te brindamos la solución y nuestro deseo es servirte de mucha apoyo.
BLOQUEAR – bloquear una mesa
Sinopsis
LOCK[TABLE][ ONLY ] name [*][,...][IN lockmode MODE][ NOWAIT ]where lockmode is one of: ACCESS SHARE|ROWSHARE|ROW EXCLUSIVE |SHAREUPDATE EXCLUSIVE |SHARE|SHAREROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE
Descripción
LOCK TABLE
obtiene un bloqueo a nivel de tabla, esperando, si es necesario, que se libere cualquier bloqueo en conflicto. Si NOWAIT
está especificado, LOCK TABLE
no espera para adquirir el bloqueo deseado: si no se puede adquirir inmediatamente, el comando se aborta y se emite un error. Una vez obtenido, el bloqueo se mantiene durante el resto de la transacción actual. (No hay UNLOCK TABLE
mando; los bloqueos siempre se liberan al final de la transacción).
Cuando una vista está bloqueada, todas las relaciones que aparecen en la consulta de definición de vista también se bloquean de forma recursiva con el mismo modo de bloqueo.
Al adquirir bloqueos automáticamente para comandos que hacen referencia a tablas, PostgreSQL siempre usa el modo de bloqueo menos restrictivo posible. LOCK TABLE
proporciona casos en los que podría necesitar un bloqueo más restrictivo. Por ejemplo, suponga que una aplicación ejecuta una transacción en el READ COMMITTED
nivel de aislamiento y debe garantizar que los datos de una tabla permanezcan estables durante la transacción. Para lograr esto podrías obtener SHARE
modo de bloqueo sobre la tabla antes de consultar. Esto evitará cambios de datos simultáneos y garantizará que las lecturas posteriores de la tabla obtengan una vista estable de los datos comprometidos, porque SHARE
el modo de bloqueo entra en conflicto con el ROW EXCLUSIVE
bloqueo adquirido por escritores, y su LOCK TABLE name IN SHARE MODE
declaración esperará hasta que cualquier titular concurrente de ROW EXCLUSIVE
el modo bloquea la confirmación o la reversión. Por lo tanto, una vez que obtenga el bloqueo, no hay escrituras no confirmadas pendientes; además, ninguno puede comenzar hasta que suelte el candado.
Para lograr un efecto similar al ejecutar una transacción en el REPEATABLE READ
o SERIALIZABLE
nivel de aislamiento, tienes que ejecutar el LOCK TABLE
declaración antes de ejecutar cualquier SELECT
o declaración de modificación de datos. A REPEATABLE READ
o SERIALIZABLE
La vista de los datos de la transacción se congelará cuando su primera SELECT
o comienza la declaración de modificación de datos. A LOCK TABLE
más adelante en la transacción aún evitará escrituras simultáneas, pero no garantizará que lo que lea la transacción corresponda a los últimos valores comprometidos.
Si una transacción de este tipo va a cambiar los datos en la tabla, entonces debería usar SHARE ROW EXCLUSIVE
modo de bloqueo en lugar de SHARE
modo. Esto asegura que solo se ejecute una transacción de este tipo a la vez. Sin esto, es posible un punto muerto: dos transacciones pueden adquirir SHARE
modo, y luego ser incapaz de adquirir también ROW EXCLUSIVE
modo para realizar sus actualizaciones. (Tenga en cuenta que los bloqueos propios de una transacción nunca entran en conflicto, por lo que una transacción puede adquirir ROW EXCLUSIVE
modo cuando sostiene SHARE
modo, pero no si alguien más tiene SHARE
modo.) Para evitar interbloqueos, asegúrese de que todas las transacciones adquieran bloqueos en los mismos objetos en el mismo orden, y si hay varios modos de bloqueo involucrados para un solo objeto, las transacciones siempre deben adquirir primero el modo más restrictivo.
Puede encontrar más información sobre los modos de bloqueo y las estrategias de bloqueo en la Sección 13.3.
Parámetros
name
-
El nombre (opcionalmente calificado por esquema) de una tabla existente para bloquear. Si
ONLY
se especifica antes del nombre de la tabla, solo esa tabla está bloqueada. SiONLY
no se especifica, la tabla y todas sus tablas descendientes (si las hay) están bloqueadas. Opcionalmente,*
se puede especificar después del nombre de la tabla para indicar explícitamente que se incluyen tablas descendientes.El comando
LOCK TABLE a, b;
es equivalente aLOCK TABLE a; LOCK TABLE b;
. Las tablas se bloquean una por una en el orden especificado en elLOCK TABLE
mando. lockmode
-
El modo de bloqueo especifica con qué bloqueos entra en conflicto este bloqueo. Los modos de bloqueo se describen en la Sección 13.3.
Si no se especifica ningún modo de bloqueo,
ACCESS EXCLUSIVE
, se utiliza el modo más restrictivo. NOWAIT
-
Especifica que
LOCK TABLE
no debe esperar a que se libere ningún bloqueo en conflicto: si el bloqueo especificado no se puede adquirir inmediatamente sin esperar, la transacción se aborta.
Notas
LOCK TABLE ... IN ACCESS SHARE MODE
requiere SELECT
privilegios en la tabla de destino. LOCK TABLE ... IN ROW EXCLUSIVE MODE
requiere INSERT
, UPDATE
, DELETE
, o TRUNCATE
privilegios en la tabla de destino. Todas las demás formas de LOCK
requiere nivel de mesa UPDATE
, DELETE
, o TRUNCATE
privilegios.
El usuario que realiza el bloqueo en la vista debe tener el privilegio correspondiente en la vista. Además, el propietario de la vista debe tener los privilegios pertinentes sobre las relaciones base subyacentes, pero el usuario que realiza el bloqueo no necesita ningún permiso sobre las relaciones base subyacentes.
LOCK TABLE
es inútil fuera de un bloque de transacción: el bloqueo permanecería retenido solo hasta la finalización de la declaración. Por lo tanto, PostgreSQL informa de un error si LOCK
se utiliza fuera de un bloque de transacciones. Utilice BEGIN y COMMIT (o ROLLBACK) para definir un bloque de transacción.
LOCK TABLE
solo trata con bloqueos a nivel de tabla, por lo que los nombres de modo que involucran ROW
son todos nombres inapropiados. Estos nombres de modo generalmente deben leerse como una indicación de la intención del usuario de adquirir bloqueos de nivel de fila dentro de la tabla bloqueada. También, ROW EXCLUSIVE
El modo es un candado de mesa que se puede compartir. Tenga en cuenta que todos los modos de bloqueo tienen semántica idéntica en cuanto a LOCK TABLE
se refiere, difiriendo sólo en las reglas sobre qué modos entran en conflicto con cuáles. Para obtener información sobre cómo adquirir un bloqueo de nivel de fila real, consulte la Sección 13.3.2 y La cláusula de bloqueo en la documentación de SELECT.
Ejemplos de
Obtener un SHARE
bloquear en una primaria key tabla cuando vaya a realizar inserciones en un exterior key mesa:
BEGINWORK;LOCKTABLE films INSHAREMODE;SELECT id FROM films WHERE name ='Star Wars: Episode I - The Phantom Menace';-- Do ROLLBACK if record was not returnedINSERTINTO films_user_comments VALUES(_id_,'GREAT! I was waiting for it for so long!');COMMITWORK;
Tomar un SHARE ROW EXCLUSIVE
bloquear en una primaria key tabla cuando vaya a realizar una operación de eliminación:
BEGINWORK;LOCKTABLE films INSHAREROW EXCLUSIVE MODE;DELETEFROM films_user_comments WHERE id IN(SELECT id FROM films WHERE rating <5);DELETEFROM films WHERE rating <5;COMMITWORK;
Compatibilidad
No hay LOCK TABLE
en el estándar SQL, que en su lugar utiliza SET TRANSACTION
para especificar niveles de simultaneidad en transacciones. PostgreSQL también lo admite; consulte CONFIGURAR TRANSACCIÓN para obtener más detalles.
Excepto por ACCESS SHARE
, ACCESS EXCLUSIVE
, y SHARE UPDATE EXCLUSIVE
modos de bloqueo, los modos de bloqueo de PostgreSQL y el LOCK TABLE
la sintaxis son compatibles con las presentes en Oracle.
Anterior | Hasta | próximo |
CARGA | Hogar | MOVERSE |
valoraciones y reseñas
Tienes la opción de añadir valor a nuestro contenido añadiendo tu experiencia en las críticas.