Catálogos de Postgresql: pg_locks

La vista pg_locks proporciona acceso a información sobre los bloqueos mantenidos por procesos activos dentro del servidor de la base de datos. Ver Capítulo 13 para más información sobre el bloqueo.

pg_locks contiene una fila por objeto bloqueable activo, modo de bloqueo solicitado y proceso relevante. Por lo tanto, el mismo objeto bloqueable puede aparecer muchas veces, si varios procesos están reteniendo o esperando bloqueos en él. Sin embargo, un objeto que actualmente no tiene bloqueos no aparecerá en absoluto.

Hay varios tipos distintos de objetos bloqueables: relaciones completas (por ejemplo, tablas), páginas individuales de relaciones, tuplas individuales de relaciones, ID de transacciones (ID virtuales y permanentes) y objetos de base de datos generales (identificados por clase OID y objeto OID, de la misma manera que en pg_description o pg_depend). Además, el derecho a extender una relación se representa como un objeto bloqueable separado, al igual que el derecho a actualizar pg_database.datfrozenxid. También, “consultivo“ Los bloqueos se pueden tomar en números que tienen significados definidos por el usuario.

Tabla 51.74. pg_locks Columnas

granted es true en una fila que representa un candado mantenido por el proceso indicado. Falso indica que este proceso está esperando actualmente para adquirir este bloqueo, lo que implica que al menos otro proceso está reteniendo o esperando un modo de bloqueo en conflicto en el mismo objeto bloqueable. El proceso de espera dormirá hasta que se libere el otro bloqueo (o se detecte una situación de interbloqueo). Un solo proceso puede estar esperando para adquirir como máximo un candado a la vez.

Durante la ejecución de una transacción, un proceso de servidor mantiene un bloqueo exclusivo en el ID de transacción virtual de la transacción. Si se asigna un ID permanente a la transacción (lo que normalmente ocurre solo si la transacción cambia el estado de la base de datos), también mantiene un bloqueo exclusivo en el ID de transacción permanente de la transacción hasta que finaliza. Cuando un proceso considera necesario esperar específicamente a que finalice otra transacción, lo hace intentando adquirir un bloqueo compartido en el ID de la otra transacción (ya sea un ID virtual o permanente, según la situación). Eso tendrá éxito solo cuando la otra transacción finalice y libere sus bloqueos.

Aunque las tuplas son un tipo de objeto que se puede bloquear, la información sobre los bloqueos de nivel de fila se almacena en el disco, no en la memoria y, por lo tanto, los bloqueos de nivel de fila normalmente no aparecen en esta vista. Si un proceso está esperando un bloqueo de nivel de fila, generalmente aparecerá en la vista como esperando el ID de transacción permanente del titular actual de ese bloqueo de fila.

Los bloqueos de aviso se pueden adquirir en keys que consiste en un solo bigint valor o dos valores enteros. A bigint key se muestra con su mitad de orden superior en el classid columna, su mitad de orden inferior en el objid columna y objsubid igual a 1. El original bigint el valor se puede reensamblar con la expresión (classid::bigint << 32) | objid::bigint. Entero keys se muestran con el primer key en el classid columna, la segunda key en el objid columna y objsubid igual a 2. El significado real de la keys depende del usuario. Los bloqueos de aviso son locales para cada base de datos, por lo que database La columna es significativa para un bloqueo de aviso.

pg_locks proporciona una vista global de todos los bloqueos en el clúster de la base de datos, no solo los relevantes para la base de datos actual. Aunque es relation la columna se puede unir contra pg_class.oid para identificar relaciones bloqueadas, esto solo funcionará correctamente para las relaciones en la base de datos actual (aquellas para las que el database columna es el OID de la base de datos actual o cero).

los pid La columna se puede unir a la pid columna de la pg_stat_activity Ver para obtener más información sobre la sesión en espera o en espera de cada bloqueo, por ejemplo

SELECT*FROM pg_locks pl LEFTJOIN pg_stat_activity psa
    ON pl.pid = psa.pid;

Además, si está utilizando transacciones preparadas, el virtualtransaction La columna se puede unir a la transaction columna de la pg_prepared_xacts ver para obtener más información sobre transacciones preparadas que mantienen bloqueos. (Una transacción preparada nunca puede estar esperando un bloqueo, pero continúa reteniendo los bloqueos que adquirió mientras se ejecuta). Por ejemplo:

SELECT*FROM pg_locks pl LEFTJOIN pg_prepared_xacts ppx
    ON pl.virtualtransaction ='-1/'|| ppx.transaction;

Si bien es posible obtener información sobre qué procesos bloquean qué otros procesos al unirse pg_locks contra sí mismo, esto es muy difícil de precisar en detalle. Tal consulta tendría que codificar el conocimiento sobre qué modos de bloqueo entran en conflicto con otros. Peor aún, el pg_locks view no expone información sobre qué procesos están por delante de otros en las colas de espera bloqueadas, ni información sobre qué procesos son trabajadores paralelos que se ejecutan en nombre de qué otras sesiones de cliente. Es mejor usar el pg_blocking_pids() función (ver Tabla 9.63) para identificar qué proceso (s) se bloquea detrás de un proceso en espera.

los pg_locks ver muestra datos tanto del administrador de bloqueo normal como del administrador de bloqueo de predicado, que son sistemas separados; Además, el administrador de cerraduras regular subdivide sus cerraduras en regular y Camino rápido Cerraduras. No se garantiza que estos datos sean completamente consistentes. Cuando se consulta la vista, los datos de los bloqueos de ruta rápida (con fastpath = true) se recopila de cada backend uno a la vez, sin congelar el estado de todo el administrador de bloqueos, por lo que es posible que se tomen o liberen bloqueos mientras se recopila información. Sin embargo, tenga en cuenta que se sabe que estos bloqueos no entran en conflicto con ningún otro bloqueo actualmente en su lugar. Una vez que se han consultado todos los backends para ver si hay bloqueos de ruta rápida, el resto del administrador de bloqueos normal se bloquea como una unidad y se recopila una instantánea coherente de todos los bloqueos restantes como acción atómica. Después de desbloquear el administrador de bloqueo normal, el administrador de bloqueo de predicado se bloquea de manera similar y todos los bloqueos de predicado se recopilan como una acción atómica. Por lo tanto, con la excepción de los bloqueos de ruta rápida, cada administrador de bloqueos entregará un conjunto consistente de resultados, pero como no bloqueamos ambos administradores de bloqueos simultáneamente, es posible que los bloqueos se activen o liberen después de interrogar al administrador de bloqueos habitual. y antes de interrogar al administrador de bloqueo de predicados.

Bloquear el administrador de bloqueo regular y / o de predicado podría tener algún impacto en el rendimiento de la base de datos si se accede a esta vista con mucha frecuencia. Los bloqueos se mantienen solo durante el tiempo mínimo necesario para obtener datos de los administradores de bloqueos, pero esto no elimina por completo la posibilidad de un impacto en el rendimiento.