http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Veamos. El n\u00famero de transacci\u00f3n est\u00e1 marcado en rojo. Aqu\u00ed se muestra la funci\u00f3n SELECT pg_back. Devuelve mi transacci\u00f3n y el ID de esta transacci\u00f3n. <\/p>\n
<\/p>\n
Otro punto, si te gusta esta presentaci\u00f3n y deseas ejecutarla en tu base de datos, puedes seguir este enlace resaltado en rosa y descargar el SQL para esta presentaci\u00f3n. Puedes ejecutarlo en tu PSQL y la presentaci\u00f3n aparecer\u00e1 en tu pantalla de inmediato. No contendr\u00e1 colores, pero al menos podremos verla.<\/p>\n
<\/p>\n
<\/p>\n
En este caso, vemos el ID de la transacci\u00f3n. Este es el n\u00famero que le hemos asignado. Y hay otro tipo de ID de transacci\u00f3n en Postgres, que se llama ID de transacci\u00f3n virtual.<\/p>\n
<\/p>\n
Y debemos entender esto. Es muy importante, de lo contrario no podremos entender el bloqueo en Postgres.<\/p>\n
<\/p>\n
El ID de transacci\u00f3n virtual es un ID de transacci\u00f3n que no contiene valores persistentes. Por ejemplo, si ejecuto un comando SELECT, es probable que no cambie la base de datos, no estar\u00e9 bloqueando nada. Por lo tanto, cuando ejecutamos un simple SELECT, no le damos a esta transacci\u00f3n un ID persistente. Solo le damos un ID virtual.<\/p>\n
<\/p>\n
Y esto mejora el rendimiento de Postgres, optimiza las capacidades de limpieza, por eso el ID de transacci\u00f3n virtual se compone de dos n\u00fameros. El primer n\u00famero antes de la barra diagonal es el ID del backend. A la derecha simplemente vemos un contador.<\/p>\n
<\/p>\n
<\/p>\n
Por lo tanto, si ejecuto una consulta, dice que el ID del backend es 2. <\/p>\n
<\/p>\n
<\/p>\n
Y si ejecuto una serie de estas transacciones, vemos que el contador aumenta cada vez que ejecuto una consulta. Por ejemplo, cuando ejecuto las consultas 2\/10, 2\/11, 2\/12, etc. <\/p>\n
<\/p>\n
<\/p>\n
Ten en cuenta que aqu\u00ed hay dos columnas. A la izquierda vemos el ID de transacci\u00f3n virtual: 2\/12. Y a la derecha tenemos el ID de transacci\u00f3n persistente. Este campo est\u00e1 vac\u00edo. Y esta transacci\u00f3n no modifica la base de datos. Por lo tanto, no le asigno un ID de transacci\u00f3n persistente.<\/p>\n
<\/p>\n
<\/p>\n
Tan pronto como ejecuto el comando analizar (ANALYZE), la misma consulta me da un ID de transacci\u00f3n persistente. Observa c\u00f3mo ha cambiado. Antes no ten\u00eda este ID, ahora lo tengo.<\/p>\n
<\/p>\n
<\/p>\n
As\u00ed que aqu\u00ed hay otra consulta, otra transacci\u00f3n. El n\u00famero de transacci\u00f3n virtual es 2\/13. Y si pido el ID de transacci\u00f3n persistente, lo obtendr\u00e9 cuando ejecute la consulta. <\/p>\n
<\/p>\n
<\/p>\n
As\u00ed que, una vez m\u00e1s. Tenemos un ID de transacci\u00f3n virtual y un ID de transacci\u00f3n persistente. Solo entiende este punto para comprender el comportamiento de Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Pasamos a la tercera secci\u00f3n. Aqu\u00ed simplemente revisaremos los diferentes tipos de bloqueos en Postgres. No es muy interesante. La \u00faltima secci\u00f3n ser\u00e1 mucho m\u00e1s interesante. Pero debemos considerar lo b\u00e1sico, de lo contrario no entenderemos lo que seguir\u00e1. <\/p>\n
<\/p>\n
Revisaremos esta secci\u00f3n, miraremos cada tipo de bloqueos. Y les mostrar\u00e9 ejemplos de c\u00f3mo se establecen, c\u00f3mo funcionan, les mostrar\u00e9 algunas consultas que se pueden utilizar para ver c\u00f3mo funciona el bloqueo en Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Para crear una consulta y ver qu\u00e9 sucede en Postgres, necesitamos emitir una consulta en la vista del sistema. En este caso, pg_lock est\u00e1 resaltado en rojo. Pg_lock es una tabla del sistema que nos indica qu\u00e9 bloqueos se est\u00e1n utilizando actualmente en Postgres.<\/p>\n
<\/p>\n
Sin embargo, me resulta muy dif\u00edcil mostrarles pg_lock en s\u00ed, porque es bastante complicado. Por eso he creado una vista que muestra pg_locks. Y tambi\u00e9n realiza para m\u00ed un trabajo que me permite entender mejor. Es decir, excluye mis bloqueos, mi propia sesi\u00f3n, etc. Es simplemente SQL est\u00e1ndar y me permite mostrarles mejor lo que est\u00e1 sucediendo. <\/p>\n
<\/p>\n
<\/p>\n
Otro problema es que esta vista es muy amplia, por lo que tengo que crear una segunda: lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
As\u00ed que hemos creado una tabla llamada Lockdemo. Y all\u00ed creamos una fila. Esta es nuestra tabla de muestra. Y vamos a crear secciones para simplemente mostrarles ejemplos de bloqueos. <\/p>\n
<\/p>\n
<\/p>\n
As\u00ed que, una fila, una columna. El primer tipo de bloqueo se llama ACCESS SHARE. Este es el bloqueo menos restrictivo. Esto significa que pr\u00e1cticamente no entra en conflicto con otros bloqueos.<\/p>\n
<\/p>\n
Y si queremos definir expl\u00edcitamente un bloqueo, ejecutamos el comando \u00ablock table\u00bb. Esto bloquear\u00e1 la tabla de manera clara, es decir, en modo ACCESS SHARE ejecutamos lock table. Y si inicio PSQL en segundo plano, estoy creando as\u00ed una segunda sesi\u00f3n desde mi primera sesi\u00f3n. Es decir, \u00bfqu\u00e9 har\u00e9 aqu\u00ed? Cambio a la otra sesi\u00f3n y le digo \u00abmu\u00e9strame el lockview para esta consulta\u00bb. Y aqu\u00ed tengo AccessShareLock en esta tabla. Eso es exactamente lo que estaba solicitando. Y dice que se ha asignado un bloqueo. Muy f\u00e1cil. <\/p>\n
<\/p>\n
<\/p>\n
Luego, si miramos la segunda columna, no hay nada all\u00ed. Est\u00e1n vac\u00edas. <\/p>\n
<\/p>\n
<\/p>\n
Y si ejecuto el comando \u00abSELECT\u00bb, es una forma impl\u00edcita (expl\u00edcita) de solicitar AccessShareLock. Por lo tanto, libero mi tabla y ejecuto la consulta, y esta devuelve varias filas. Y en una de las filas vemos AccessShareLock. De este modo, SELECT provoca AccessShareLock en la tabla. Y pr\u00e1cticamente no entra en conflicto con nada, porque es un bloqueo de bajo nivel. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 pasa si ejecuto SELECT y tengo tres tablas diferentes? Antes solo ejecutaba una tabla, ahora estoy ejecutando tres: pg_class, pg_namespace y pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Y ahora, cuando miro la consulta, veo 9 AccessShareLocks en tres tablas. \u00bfPor qu\u00e9? Las tres tablas est\u00e1n destacadas en azul: pg_attribute, pg_class, pg_namespace. Pero tambi\u00e9n puedes ver que todos los \u00edndices que est\u00e1n definidos a trav\u00e9s de estas tablas tambi\u00e9n tienen AccessShareLock.<\/p>\n
<\/p>\n
Y este es un bloqueo que pr\u00e1cticamente no entra en conflicto con otros. Y todo lo que hace es simplemente no permitirnos liberar la tabla mientras la estamos seleccionando. Tiene sentido. Es decir, si seleccionamos una tabla y desaparece en ese momento, eso ser\u00eda incorrecto, por lo tanto. AccessShare es un bloqueo de bajo nivel que nos dice \"no elimines esta tabla mientras estoy trabajando\"<\/strong>. En esencia, eso es todo lo que hace. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE es un tipo de bloqueo que es un poco diferente. <\/p>\n
<\/p>\n
<\/p>\n
Tomemos un ejemplo. SELECT ROW SHARE es la forma de bloquear cada fila individualmente.<\/strong>. De este modo, nadie puede eliminarlas o modificarlas mientras las estamos mirando. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Aqu\u00ed decimos que el bloqueo es utilizado por nosotros.<\/p>\n
<\/p>\n
<\/p>\n
Entonces, el bloqueo exclusivo indica expl\u00edcitamente que es exclusivo. Y tambi\u00e9n, si eliminas una fila en esta tabla, eso es lo que suceder\u00e1, como puedes ver. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE es un bloqueo m\u00e1s prolongado.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Este es el comando ANALYZE que se va a utilizar.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK te permite bloquear expl\u00edcitamente en modo compartido.<\/p>\n
<\/p>\n
<\/p>\n
Tambi\u00e9n puedes crear un \u00edndice \u00fanico. Y all\u00ed puedes ver el SHARE LOCK, que es parte de ellos. Y bloquea la tabla y aplica el SHARE LOCK sobre ella.<\/p>\n
<\/p>\n
Por defecto, el SHARE LOCK en la tabla significa que otras personas pueden leer la tabla, pero nadie puede modificarla. Y eso es lo que sucede cuando creas un \u00edndice \u00fanico.<\/strong><\/p>\n<\/p>\n
Si creo un \u00edndice \u00fanico concurrentemente, tendr\u00e9 otro tipo de bloqueo, porque, como recordar\u00e1s, el uso de \u00edndices concurrentes reduce la necesidad de bloqueo. Y si utilizo un bloqueo normal con un \u00edndice normal, estar\u00e9 previniendo as\u00ed la escritura en la tabla del \u00edndice durante su creaci\u00f3n. Si utilizo un \u00edndice concurrente, tendr\u00e9 que usar otro tipo de bloqueo. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE, nuevamente puede ser asignado expl\u00edcitamente.<\/p>\n
<\/p>\n
<\/p>\n
O podemos crear una regla, es decir, tomar un caso espec\u00edfico en el que se va a utilizar.<\/p>\n
<\/p>\n
<\/p>\n
El bloqueo EXCLUSIVE significa que nadie m\u00e1s podr\u00e1 modificar la tabla. <\/p>\n
<\/p>\n
<\/p>\n
Aqu\u00ed vemos diferentes tipos de bloqueos. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, por ejemplo, es un comando de bloqueo. Por ejemplo, si haces CLUSTER table<\/code>, eso significar\u00e1 que nadie podr\u00e1 escribir en ella. Y bloquea no solo la tabla misma, sino tambi\u00e9n los \u00edndices.<\/p>\n<\/p>\n
<\/p>\n
Esta es la segunda p\u00e1gina del bloqueo ACCESS EXCLUSIVE, donde vemos espec\u00edficamente lo que est\u00e1 bloqueando en la tabla. Est\u00e1 bloqueando filas individuales de la tabla, lo cual es bastante interesante.<\/p>\n
<\/p>\n
Esta es toda la informaci\u00f3n b\u00e1sica que quer\u00eda proporcionar. Hablamos sobre bloqueos, sobre ID de transacciones, mencionamos ID virtuales de transacciones y sobre ID de transacciones permanentes. <\/p>\n
<\/p>\n
<\/p>\n
Ahora revisaremos ejemplos de bloqueos. Esta es la parte m\u00e1s interesante. Veremos casos muy interesantes. Y mi tarea en esta presentaci\u00f3n es darte una mejor idea de lo que realmente hace Postgres cuando intenta bloquear ciertos elementos. Me parece que lo hace muy bien bloqueando partes espec\u00edficas. <\/p>\n
<\/p>\n
Examinemos ciertos ejemplos.<\/p>\n
<\/p>\n
<\/p>\n
Comenzaremos con tablas y una fila en la tabla. Cuando inserto algo, se muestra un ExclusiveLock, el ID de la transacci\u00f3n y un ExclusiveLock en la tabla. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfY qu\u00e9 pasar\u00e1 si inserto dos filas m\u00e1s? Ahora nuestra tabla tiene tres filas. Insert\u00e9 una fila y obtuve esto como salida. Y si inserto dos filas m\u00e1s, \u00bfqu\u00e9 hay de extra\u00f1o aqu\u00ed? Hay algo extra\u00f1o, porque a\u00f1ad\u00ed tres filas a esta tabla, pero todav\u00eda tengo dos filas en la tabla de bloqueos. Y esto, en esencia, es el comportamiento fundamental de Postgres.<\/p>\n
<\/p>\n
Muchos piensan que si en la base de datos bloqueas 100 filas, necesitar\u00e1s crear 100 entradas de bloqueos. Si bloqueo de una vez 1,000 filas, entonces necesitar\u00e9 1,000 de tales solicitudes. Y si necesito bloquear un mill\u00f3n o mil millones. Pero hacer esto no funcionar\u00eda muy bien. Si has utilizado un sistema que crea entradas de bloqueos para cada fila individual, ver\u00e1s que esto es complicado. Porque necesitas definir de inmediato la tabla de bloqueos, que podr\u00eda desbordarse, pero Postgres no lo hace. <\/p>\n
<\/p>\n
Y en esta diapositiva es muy importante notar que aqu\u00ed se demuestra claramente que hay otro sistema que funciona dentro del MVCC, que bloquea filas individuales. Por lo tanto, cuando bloqueas miles de millones de filas, Postgres no crea mil millones de comandos de bloqueo individuales. Y esto mejora mucho el rendimiento. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfY qu\u00e9 pasa con la actualizaci\u00f3n? Ahora estoy actualizando una fila, y puedes notar que realiz\u00f3 dos operaciones diferentes al mismo tiempo. Bloque\u00f3 la tabla, pero tambi\u00e9n bloque\u00f3 el \u00edndice. Y necesitaba bloquear el \u00edndice porque hay restricciones \u00fanicas en esta tabla. Y queremos asegurarnos de que nadie lo cambie, as\u00ed que lo bloqueamos.<\/p>\n
<\/p>\n
<\/p>\n
\u00bfY qu\u00e9 suceder\u00e1 si quiero actualizar dos filas? Y vemos que se comporta de la misma manera. Realizamos el doble de actualizaciones, pero exactamente la misma cantidad de filas bloqueadas. <\/p>\n
<\/p>\n
Si te interesa c\u00f3mo lo hace Postgres, necesitas escuchar mis presentaciones sobre MVCC para comprender c\u00f3mo Postgres marca internamente las filas que cambia. Y Postgres tiene una forma de hacerlo, pero no lo realiza a nivel de bloqueo de tablas, lo hace a un nivel m\u00e1s bajo y m\u00e1s eficiente.<\/p>\n
<\/p>\n
<\/p>\n
\u00bfY si quiero eliminar algo? Si elimino, por ejemplo, una fila y a\u00fan tengo mis dos bloqueos en espera, incluso si quiero eliminarlas todas, todav\u00eda est\u00e1n ah\u00ed.<\/p>\n
<\/p>\n
<\/p>\n
Y, por ejemplo, si quiero insertar 1,000 filas, y luego eliminar o agregar 1,000 filas, esas filas individuales que agrego o cambio no se registran aqu\u00ed. Se registran a un nivel m\u00e1s bajo dentro de la propia fila. Y durante la presentaci\u00f3n sobre MVCC habl\u00e9 de esto en detalle. Pero es muy importante, al analizar bloqueos, asegurarse de que tienes un bloqueo a nivel de tabla y que aqu\u00ed no ves c\u00f3mo se registran las filas individuales. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfY qu\u00e9 pasa con el bloqueo expl\u00edcito?<\/p>\n
<\/p>\n
<\/p>\n
Si presiono 'actualizar', tengo dos filas bloqueadas. Y si las selecciono todas y presiono 'actualizar todo', a\u00fan tendr\u00e9 dos registros bloqueados. <\/p>\n
<\/p>\n
<\/p>\n
No creamos registros separados para cada fila individual. Porque eso disminuir\u00eda el rendimiento, podr\u00eda haber demasiados. Y podr\u00edamos encontrarnos en una situaci\u00f3n inc\u00f3moda. <\/p>\n
<\/p>\n
<\/p>\n
Y lo mismo sucede, si hacemos un bloqueo compartido, podemos hacerlo 30 veces. <\/p>\n
<\/p>\n
<\/p>\n
Restauramos nuestra tabla, eliminamos todo, luego insertamos una fila de nuevo.<\/p>\n
<\/p>\n
<\/p>\n
Otro comportamiento que se observa en Postgres es el bien conocido y deseado comportamiento: puedes realizar actualizaciones o selecciones. Y puedes hacerlo simult\u00e1neamente. La selecci\u00f3n no bloquea la actualizaci\u00f3n y viceversa. Estamos diciendo que el que lee no bloquea a quien escribe, y quien escribe no bloquea al lector. <\/p>\n
<\/p>\n
Te mostrar\u00e9 un ejemplo de esto. Har\u00e9 una selecci\u00f3n ahora. Luego haremos un INSERT. Y despu\u00e9s podr\u00e1s ver \u2013 694. Podr\u00e1s ver el ID de la transacci\u00f3n que realiz\u00f3 esta inserci\u00f3n. Y as\u00ed es como funciona. <\/p>\n
<\/p>\n
<\/p>\n
Y si ahora miro mi ID de backend, se ha convertido en \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Y puedo ver que 695 aparece en mi tabla. <\/p>\n
<\/p>\n
<\/p>\n
Y si realizo una actualizaci\u00f3n aqu\u00ed de esta manera, obtengo otro caso. En este caso, 695 tiene un bloqueo exclusivo, y la actualizaci\u00f3n tiene un comportamiento similar, pero entre ellos no surge un conflicto, lo cual es bastante inusual. <\/p>\n
<\/p>\n
Y puedes notar que en la parte superior \u2013 es un ShareLock, y abajo \u2013 es un ExclusiveLock. Y ambas transacciones se lograron.<\/p>\n
<\/p>\n
Y debes escuchar mi presentaci\u00f3n sobre MVCC para entender c\u00f3mo sucede esto. Pero esta es una ilustraci\u00f3n de que puedes hacer esto simult\u00e1neamente, es decir, realizar SELECT y UPDATE al mismo tiempo.<\/p>\n
<\/p>\n
<\/p>\n
Vamos a reiniciar y hacer una operaci\u00f3n m\u00e1s. <\/p>\n
<\/p>\n
<\/p>\n
Si intentas ejecutar dos actualizaciones simult\u00e1neamente en la misma fila, se bloquear\u00e1. Y recuerda, dije que el que lee no bloquea al escritor, y el escritor al lector, pero un escritor bloquea a otro escritor. Es decir, no podemos hacer que dos personas actualicen la misma fila al mismo tiempo. Hay que esperar a que uno de ellos termine. <\/p>\n
<\/p>\n
<\/p>\n
Y para ilustrar esto, mirar\u00e9 la tabla Lockdemo. Y veremos una fila. En la transacci\u00f3n 698.<\/p>\n
<\/p>\n
Lo actualizamos a 2. 699 \u2013 es la primera actualizaci\u00f3n. Y fue exitosa o est\u00e1 en una transacci\u00f3n pendiente, esperando que confirmemos o cancelemos. <\/p>\n
<\/p>\n
<\/p>\n
Pero miren otra cosa: 2\/51 es nuestra primera transacci\u00f3n, nuestra primera sesi\u00f3n. 3\/112 es la segunda solicitud que apareci\u00f3 encima y que cambi\u00f3 este valor a 3. Y si lo notan, el superior se bloque\u00f3 a s\u00ed mismo, el que es 699. Pero 3\/112 no proporcion\u00f3 bloqueo. En la columna Lock_mode dice que est\u00e1 esperando. Est\u00e1 esperando a 699. Y si miran d\u00f3nde est\u00e1 699, est\u00e1 arriba. \u00bfY qu\u00e9 hizo la primera sesi\u00f3n? Cre\u00f3 un bloqueo exclusivo en su propio ID transaccional. As\u00ed es como Postgres lo hace. Bloquea su propio ID transaccional. Y si quieren esperar a que alguien confirme o cancele, deben esperar hasta que haya una transacci\u00f3n pendiente. Por eso podemos ver esa l\u00ednea extra\u00f1a. <\/p>\n
<\/p>\n
Veamos una vez m\u00e1s. A la izquierda vemos nuestro ID de procesamiento. En la segunda columna vemos nuestro ID virtual de transacci\u00f3n, y en la tercera vemos el lock_type. \u00bfQu\u00e9 significa esto? B\u00e1sicamente, dice que est\u00e1 bloqueando el ID transaccional. Pero noten que en todas las filas abajo dice relation. Y por eso tienen dos tipos de bloqueo en la tabla. Hay un bloqueo de relaci\u00f3n. Y tambi\u00e9n hay un bloqueo de transactionid, donde bloquean por su cuenta, que es precisamente lo que sucede en la primera fila o en la parte m\u00e1s baja, donde transactionid, donde estamos esperando a que 699 termine su operaci\u00f3n. <\/p>\n
<\/p>\n
Estoy observando lo que est\u00e1 ocurriendo aqu\u00ed. Y aqu\u00ed sucede dos cosas simult\u00e1neamente. Est\u00e1n viendo el bloqueo por ID transaccional en la primera fila, que se bloquea a s\u00ed mismo. Y se bloquea a s\u00ed mismo para hacer que la gente espere. <\/p>\n
<\/p>\n
Si miran la sexta l\u00ednea, ver\u00e1n que el mismo registro que el primero. Y por eso la transacci\u00f3n 699 se est\u00e1 bloqueando. 700 tambi\u00e9n se bloquea a s\u00ed mismo. Y luego en la fila inferior ver\u00e1n que estamos esperando a que 699 termine su operaci\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
Y en lock_type, tuple, ven los n\u00fameros. <\/p>\n
<\/p>\n
<\/p>\n
Pueden ver que es 0\/10. Y ese es el n\u00famero de p\u00e1gina, y tambi\u00e9n el offset de esta fila espec\u00edfica. <\/p>\n
<\/p>\n
<\/p>\n
Y ven que se convierte en 0\/11 cuando actualizamos. <\/p>\n
<\/p>\n
<\/p>\n
Pero en realidad, es 0\/10, porque hay una espera en esta operaci\u00f3n. Tenemos la oportunidad de observar que esta es la fila que estoy esperando para confirmar. <\/p>\n
<\/p>\n
<\/p>\n
Una vez que lo confirmamos y presionamos commit, y cuando se termin\u00f3 la actualizaci\u00f3n, esto es lo que obtenemos de nuevo. La transacci\u00f3n 700 es el \u00fanico bloqueo, no est\u00e1 esperando a nadie m\u00e1s porque se ha comprometido. Simplemente est\u00e1 esperando a que la transacci\u00f3n finalice. Una vez que 699 termina, no estamos esperando m\u00e1s nada. Y ahora la transacci\u00f3n 700 dice que todo est\u00e1 bien, que tiene todos los bloqueos necesarios en todas las tablas permitidas. <\/p>\n
<\/p>\n
<\/p>\n
Y para complicar a\u00fan m\u00e1s las cosas, estamos creando otra vista que en esta ocasi\u00f3n nos proporcionar\u00e1 una jerarqu\u00eda. No espero que entiendas esta consulta. Pero nos dar\u00e1 una visi\u00f3n m\u00e1s clara de lo que est\u00e1 sucediendo. <\/p>\n
<\/p>\n
<\/p>\n
Esta es una vista recursiva, que tambi\u00e9n tiene otra secci\u00f3n. Y luego vuelve todo junto. Vamos a utilizar esto. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 pasar\u00eda si hacemos tres actualizaciones simult\u00e1neas y decimos que la fila es ahora tres? Y cambiamos 3 a 4. <\/p>\n
<\/p>\n
<\/p>\n
Y aqu\u00ed vemos 4. Y el ID de transacci\u00f3n 702. <\/p>\n
<\/p>\n
<\/p>\n
Y luego cambiar\u00e9 4 a 5. Y 5 a 6, y 6 a 7. Y estoy poniendo en cola a un grupo de personas que estar\u00e1n esperando a que finalice esta \u00fanica transacci\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
Y todo se vuelve claro. \u00bfCu\u00e1l es la primera fila? Es 702. Este es el ID de transacci\u00f3n que originalmente estableci\u00f3 este valor. \u00bfY qu\u00e9 tengo escrito en la columna Granted? Tengo anotaciones f<\/code>. Estas son aquellas actualizaciones (5, 6, 7) que no pueden ser aprobadas porque estamos esperando que el ID de transacci\u00f3n 702 termine. Tenemos un bloqueo del ID de transacci\u00f3n. Y as\u00ed obtenemos 5 bloqueos de transacci\u00f3n ID.<\/p>\n<\/p>\n
Y si miras el 704, el 705, no hay nada escrito all\u00ed, porque a\u00fan no saben lo que est\u00e1 pasando. Simplemente est\u00e1n escribiendo que no tienen idea de lo que sucede. Y simplemente se ir\u00e1n a dormir, porque est\u00e1n esperando a que alguien termine y los despierte cuando haya una oportunidad de cambiar la fila. <\/p>\n
<\/p>\n
<\/p>\n
As\u00ed es como se ve. Es evidente que todos est\u00e1n esperando la fila 12. <\/p>\n
<\/p>\n
<\/p>\n
Esto es lo que vimos aqu\u00ed. Aqu\u00ed est\u00e1 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
As\u00ed que una vez que la primera transacci\u00f3n es aprobada, puedes aqu\u00ed ver c\u00f3mo funciona la jerarqu\u00eda. Y ahora todo queda claro. Todos quedan limpios. Y en realidad todos todav\u00eda est\u00e1n en espera. <\/p>\n
<\/p>\n
<\/p>\n
Esto es lo que sucede. 702 se compromete. Y ahora 703 recibe este bloqueo de fila, mientras que 704 comienza a esperar a que 703 se comprometa. Y 705 tambi\u00e9n est\u00e1 esperando eso. Y cuando todo esto se completa, se limpian a s\u00ed mismos. Y me gustar\u00eda se\u00f1alar que todos se alinean. Es muy parecido a una situaci\u00f3n de embotellamiento, donde todos esperan el primer autom\u00f3vil. El primer autom\u00f3vil se detuvo y todos se alinean en una larga fila. Luego avanza, y el siguiente autom\u00f3vil puede avanzar y obtener su bloqueo, y as\u00ed sucesivamente. <\/p>\n
<\/p>\n
<\/p>\n
Y si esto te parece poco complicado, ahora hablaremos sobre los deadlocks. No s\u00e9 qui\u00e9n de ustedes se ha encontrado con ellos. Es un problema bastante com\u00fan en los sistemas de bases de datos. Pero los deadlocks son el caso en que una sesi\u00f3n espera a que otra sesi\u00f3n realice algo. Y en ese momento, la otra sesi\u00f3n espera a que la primera sesi\u00f3n complete algo. <\/p>\n
<\/p>\n
Y, por ejemplo, si Iv\u00e1n dice: 'Dame algo', y yo digo: 'No, solo te lo dar\u00e9 si me das algo a cambio'. Y \u00e9l responde: 'No, no te dar\u00e9 eso a menos que me des algo primero'. Y nos encontramos en una situaci\u00f3n de deadlock. Estoy seguro de que Iv\u00e1n no har\u00eda eso, pero entiendes la idea: tenemos a dos personas que quieren obtener algo, y no est\u00e1n dispuestas a darlo hasta que la otra persona les entregue lo que desean. Y aqu\u00ed no hay soluci\u00f3n. <\/p>\n
<\/p>\n
Y, esencialmente, tu base de datos necesita identificar esto. Y luego es necesario eliminar o cerrar una de las sesiones, porque de lo contrario permanecer\u00e1n all\u00ed para siempre. Y esto lo vemos en bases de datos, lo vemos en sistemas operativos. Y en todos los lugares donde hay procesos paralelos, esto puede suceder. <\/p>\n
<\/p>\n
<\/p>\n
Ahora vamos a configurar dos deadlocks. Vamos a establecer 50 y 80. En la primera fila, realizar\u00e9 una actualizaci\u00f3n de 50 a 50. Obtendr\u00e9 el n\u00famero de transacci\u00f3n 710. <\/p>\n
<\/p>\n
<\/p>\n
Luego cambiar\u00e9 80 a 81, y 50 a 51. <\/p>\n
<\/p>\n
<\/p>\n
Y as\u00ed es como se ver\u00e1. Por lo tanto, 710 tiene un bloqueo de fila, mientras que 711 espera confirmaci\u00f3n. Lo vimos cuando actualizamos. 710 es el propietario de nuestra fila. Y 711 est\u00e1 esperando a que 710 complete la transacci\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
Y all\u00ed tambi\u00e9n est\u00e1 escrito en qu\u00e9 fila espec\u00edfica estamos experimentando deadlocks. Y aqu\u00ed es donde comienza a volverse extra\u00f1o.<\/p>\n
<\/p>\n
<\/p>\n
Ahora actualizamos de 80 a 80. <\/p>\n
<\/p>\n
<\/p>\n
Y aqu\u00ed es donde comienzan los bloqueos. El 710 est\u00e1 esperando una respuesta del 711, y el 711 est\u00e1 esperando al 710. Y esto no terminar\u00e1 bien. Y no hay salida de esto. Y estar\u00e1n esperando una respuesta el uno del otro. <\/p>\n
<\/p>\n
<\/p>\n
Y esto simplemente comenzar\u00e1 a causar retrasos. Y eso es algo que no queremos. <\/p>\n
<\/p>\n
<\/p>\n
Y en Postgres hay formas de notar cuando esto sucede. Y cuando ocurre, obtienes este tipo de error. Y queda claro que este proceso est\u00e1 esperando un SHARE LOCK de otro proceso, es decir, que est\u00e1 bloqueado por el proceso 711. Y ese proceso estaba esperando que se otorgara SHARE LOCK en un determinado ID transaccional y fue bloqueado por otro proceso. Por lo tanto, aqu\u00ed hay una situaci\u00f3n de bloqueo muerto.<\/p>\n
<\/p>\n
<\/p>\n
\u00bfY hay bloqueos muertos de tres v\u00edas? \u00bfEs posible? S\u00ed. <\/p>\n
<\/p>\n
<\/p>\n
Estamos ingresando estos n\u00fameros en la tabla. Cambiamos 40 por 40, hacemos un bloqueo. <\/p>\n
<\/p>\n
<\/p>\n
Cambiamos 60 por 61, 80 por 81. <\/p>\n
<\/p>\n
<\/p>\n
Y luego cambiamos 80, y luego, \u00a1boom! <\/p>\n
<\/p>\n
<\/p>\n
Y el 714 ahora est\u00e1 esperando al 715. El 716 est\u00e1 esperando al 715. Y ya no se puede hacer nada con esto.<\/p>\n
<\/p>\n
<\/p>\n
Aqu\u00ed ya no son dos personas, son tres personas. Yo quiero algo de ti, este quiere algo del tercer persona, y el tercer persona quiere algo de m\u00ed. Y estamos en una espera de tres v\u00edas, porque todos estamos esperando a que otra persona complete lo que tiene que hacer. <\/p>\n
<\/p>\n
<\/p>\n
Y Postgres sabe en qu\u00e9 fila sucede esto. Y por eso te dar\u00e1 el siguiente mensaje, que muestra que tienes un problema donde tres entradas se bloquean entre s\u00ed. Y no hay restricciones. Puede ser en una situaci\u00f3n donde 20 registros se bloquean entre s\u00ed. <\/p>\n
<\/p>\n
<\/p>\n
El siguiente problema es el serializable. <\/p>\n
<\/p>\n
<\/p>\n
Si hay un bloqueo serializable especial.<\/p>\n
<\/p>\n
<\/p>\n
Y volvamos al 719. Tiene una salida completamente normal. <\/p>\n
<\/p>\n
<\/p>\n
Y puedes hacer clic para realizar una transacci\u00f3n de tipo serializable.<\/p>\n
<\/p>\n
<\/p>\n
Y ahora entiendes que tienes otro tipo de bloqueo SA, que significa serializable. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Y por eso tenemos un nuevo tipo de bloqueo llamado SARieadLock, que es un bloqueo serial y permite introducir n\u00fameros de serie.<\/p>\n
<\/p>\n
<\/p>\n
Y tambi\u00e9n puedes insertar \u00edndices \u00fanicos. <\/p>\n
<\/p>\n
<\/p>\n
En esta tabla tenemos \u00edndices \u00fanicos.<\/p>\n
<\/p>\n
<\/p>\n
Por lo tanto, si ingreso el n\u00famero 2 aqu\u00ed, tengo un 2. Pero en la parte superior inserto otro 2. Y puedes ver que el 721 tiene un bloqueo exclusivo. Pero ahora el 722 espera a que el 721 complete su operaci\u00f3n, porque no puede insertar el 2 hasta que sepa qu\u00e9 suceder\u00e1 con el 721. <\/p>\n
<\/p>\n
<\/p>\n
Y si hacemos una subtransacci\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
Aqu\u00ed est\u00e1 nuestro 723.<\/p>\n
<\/p>\n
<\/p>\n
Y si conservamos el punto y luego lo actualizamos, obtenemos un nuevo ID transaccional. Este es otro comportamiento que necesitas conocer. Si lo devolvemos, el ID transaccional se pierde. 724 se pierde. Pero ahora tenemos 725. <\/p>\n
<\/p>\n
\u00bfY qu\u00e9 estoy tratando de hacer aqu\u00ed? Estoy tratando de mostrarte ejemplos de bloqueos inusuales que puedes encontrar: ya sean bloqueos serializables o SAVEPOINT, son diferentes tipos de bloqueos que aparecer\u00e1n en la tabla de bloqueos. <\/p>\n
<\/p>\n
<\/p>\n
Esto es la creaci\u00f3n de bloqueos expl\u00edcitos, donde est\u00e1 pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Y ves que el tipo de bloqueo aqu\u00ed se enumera como advisory. Y se indica en rojo \u2018advisory\u2019. Y puedes bloquear as\u00ed simult\u00e1neamente con pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
Y para concluir, me gustar\u00eda mostrarte otra cosa sorprendente. Crear\u00e9 un nuevo tipo. Pero combinar\u00e9 la tabla pg_locks con la tabla pg_stat_activity. \u00bfY por qu\u00e9 quiero hacer esto? Porque me permitir\u00e1 ver todas las sesiones actuales y ver qu\u00e9 bloqueos est\u00e1n esperando. Y es bastante interesante cuando combinamos la tabla de bloqueos con la tabla de consultas. <\/p>\n
<\/p>\n
<\/p>\n
Y aqu\u00ed creamos pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Y actualizamos la fila en uno. Y aqu\u00ed vemos 724. Luego actualizamos nuestra fila a tres. \u00bfY qu\u00e9 ves aqu\u00ed ahora? Son consultas, es decir, ves toda la lista de consultas que se enumeran en la columna izquierda. Y luego, en el lado derecho, puedes ver los bloqueos y lo que crean. Y esto puede ser m\u00e1s claro para ti, para que no tengas que volver cada vez a cada sesi\u00f3n y ver si necesitas unirte a ella o no. Eso lo hacen por nosotros. <\/p>\n
<\/p>\n
Otra funci\u00f3n que es muy \u00fatil es pg_blocking_pids<\/code>. Puede que nunca hayas o\u00eddo hablar de ella. \u00bfQu\u00e9 hace? Nos permite decir que para esta sesi\u00f3n 11740, qu\u00e9 ID de procesos espec\u00edficos est\u00e1 esperando. Y puedes ver que 11740 est\u00e1 esperando 724. Y 724 est\u00e1 en la parte superior. Y 11306 es tu ID de proceso. B\u00e1sicamente, esta funci\u00f3n repasa tu tabla de bloqueos. Y s\u00e9 que es un poco complicado, pero logras entenderlo. En esencia, esta funci\u00f3n pasa por esta tabla de bloqueos e intenta encontrar d\u00f3nde est\u00e1 este ID de proceso, considerando los bloqueos que est\u00e1 esperando. Y tambi\u00e9n intenta calcular qu\u00e9 ID de proceso tiene aquel proceso que est\u00e1 esperando bloqueos. Por lo tanto, puedes ejecutar esta funci\u00f3n. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Y esto puede ser muy \u00fatil. Lo hemos a\u00f1adido solo desde la versi\u00f3n 9.6, por lo que esta funci\u00f3n tiene solo 5 a\u00f1os, pero es muy, muy \u00fatil. Lo mismo ocurre con la segunda consulta. Muestra exactamente lo que necesitamos ver. <\/p>\n
<\/p>\n
<\/p>\n
Esto es de lo que quer\u00eda hablar contigo. Y como esperaba, utilizamos todo nuestro tiempo porque hubo una gran cantidad de diapositivas. Las diapositivas est\u00e1n disponibles para descarga. Me gustar\u00eda agradecerte por estar aqu\u00ed. Estoy seguro de que disfrutar\u00e1s el resto de la conferencia, \u00a1muchas gracias!<\/p>\n
<\/p>\n
Preguntas:<\/p>\n
<\/p>\n
Por ejemplo, si intento actualizar filas y la segunda sesi\u00f3n intenta eliminar toda la tabla. Hasta donde entiendo, deber\u00eda haber algo como un intent lock. \u00bfHay algo as\u00ed en Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Volvamos al principio. Tal vez recuerdes que cuando haces cualquier cosa, por ejemplo, cuando haces un SELECT, emitimos un AccessShareLock. Y esto evita la eliminaci\u00f3n de la tabla. Por lo tanto, si deseas actualizar una fila en la tabla o eliminar una fila, alguien no puede eliminar toda la tabla al mismo tiempo, porque mantienes este AccessShareLock sobre toda la tabla y sobre la fila. Y tan pronto como terminas, pueden eliminarla. Pero mientras est\u00e9s cambiando algo all\u00ed, no podr\u00e1n hacerlo.<\/p>\n
<\/p>\n
Hag\u00e1moslo una vez m\u00e1s. Pasemos al ejemplo de eliminaci\u00f3n. Y ves que hay un lock exclusivo sobre toda la tabla en la fila. <\/p>\n
<\/p>\n
\u00bfSe ver\u00e1 como un lock exclusivo, correcto?<\/em><\/p>\n<\/p>\n
S\u00ed, eso parece. Entiendo de qu\u00e9 hablas. Dices que si ejecuto SELECT, tendr\u00e9 ShareExclusive, y luego lo transfiero a un estado Row Exclusive, \u00bfse convierte esto en un problema? Pero sorprendentemente, esto no crea un problema. Se parece a un aumento en el nivel de bloqueo, pero, en esencia, tengo un lock que previene la eliminaci\u00f3n. Y ahora, cuando hago este lock m\u00e1s potente, a\u00fan as\u00ed previene la eliminaci\u00f3n. Por lo tanto, no es que est\u00e9 aumentando. Es decir, ya preven\u00eda esto cuando estaba a un nivel m\u00e1s bajo, as\u00ed que cuando aumento su nivel, todav\u00eda evita la eliminaci\u00f3n de la tabla. <\/p>\n
<\/p>\n
Entiendo de qu\u00e9 hablas. Aqu\u00ed no hay un caso de aumento en el nivel de bloqueo, donde intentas liberar un bloqueo para introducir uno m\u00e1s potente. Aqu\u00ed simplemente se aumenta este mecanismo de prevenci\u00f3n, por lo que no provoca ning\u00fan conflicto. Pero es una buena pregunta. \u00a1Muchas gracias por plantearla!<\/p>\n
<\/p>\n
\u00bfQu\u00e9 necesitamos hacer para evitar una situaci\u00f3n de deadlock cuando tenemos muchas sesiones y un gran n\u00famero de usuarios?<\/em><\/p>\n<\/p>\n
Postgres detecta autom\u00e1ticamente situaciones de deadlock. Y de forma autom\u00e1tica eliminar\u00e1 una de las sesiones. La \u00fanica forma de ayudar a evitar situaciones de deadlock es bloquear a las personas en el mismo orden. Por lo tanto, cuando mires tu aplicaci\u00f3n, a menudo la causa de los deadlocks... Imaginemos que quiero bloquear dos cosas diferentes. Una aplicaci\u00f3n bloquea la tabla 1, y otra aplicaci\u00f3n bloquea la tabla 2, y luego la tabla 1. Y la forma m\u00e1s sencilla de evitar los deadlocks es observar tu aplicaci\u00f3n y tratar de asegurarte de que los bloqueos ocurran en el mismo orden en todas las aplicaciones. Y esto, por lo general, elimina el 80% de los problemas, porque diversas personas escriben estas aplicaciones. Y si los bloqueas en el mismo orden, entonces no te enfrentas a situaciones de deadlock.<\/p>\n
<\/p>\n
\u00a1Muchas gracias por tu presentaci\u00f3n! Hablaste sobre vacuum full y, si entiendo correctamente, vacuum full deforma el orden de los registros en el almacenamiento separado, por lo que mantiene los registros actuales sin cambios. \u00bfY por qu\u00e9 vacuum full requiere un acceso de bloqueo exclusivo y por qu\u00e9 entra en conflicto con las operaciones de escritura?<\/em><\/p>\n<\/p>\n
Es una buena pregunta. La raz\u00f3n es que vacuum full toma la tabla. Y, en esencia, estamos creando una nueva versi\u00f3n de la tabla. La tabla ser\u00e1 nueva. Por lo tanto, ser\u00e1 completamente una nueva versi\u00f3n de la tabla. Y el problema es que, cuando hacemos esto, no queremos que las personas la lean, porque necesitamos que vean la nueva tabla. Y por eso se conecta con la pregunta anterior. Si pudi\u00e9ramos leer al mismo tiempo, no podr\u00edamos moverla y dirigir a las personas a la nueva tabla. Tendr\u00edamos que esperar a que todos terminen de leer esta tabla, por lo que, en esencia, es una situaci\u00f3n de bloqueo exclusivo.
<\/p>\n
\u00bfEs posible agregar un tiempo de espera de bloqueo en Postgres? En Oracle, por ejemplo, puedo escribir \"seleccionar para actualizar\" y esperar 50 segundos antes de la actualizaci\u00f3n. Esto funcionaba bien para la aplicaci\u00f3n. Pero en Postgres tengo que hacerlo de inmediato y no esperar, o esperar hasta un cierto tiempo.<\/em> <\/p>\n<\/p>\n
S\u00ed, puedes establecer un tiempo de espera para tus bloqueos. Tambi\u00e9n puedes emitir un comando no way, que ser\u00e1... si no puedes obtener el bloqueo de inmediato. As\u00ed que habr\u00e1 un tiempo de espera de bloqueo o algo m\u00e1s que te permita hacerlo. Esto no se realiza a nivel sint\u00e1ctico. Se hace como una variable en el servidor. A veces no es posible usarlo.<\/p>\n
<\/p>\n
\u00bfPuedes abrir la diapositiva 75?<\/em> <\/p>\n<\/p>\n
S\u00ed.<\/p>\n
<\/p>\n
<\/p>\n
Y mi pregunta es la siguiente. \u00bfPor qu\u00e9 ambos procesos de actualizaci\u00f3n est\u00e1n esperando 703?<\/em><\/p>\n<\/p>\n
Y esa es una pregunta excelente. No entiendo, por cierto, por qu\u00e9 Postgres hace esto. Pero cuando se cre\u00f3 703, esperaba 702. Y cuando aparecen 704 y 705, parece que no saben lo que est\u00e1n esperando, porque a\u00fan no hay nada. Y Postgres act\u00faa as\u00ed: cuando no puedes obtener un bloqueo, dice '\u00bfCu\u00e1l es el sentido de procesarte?', porque ya est\u00e1s esperando a alguien. As\u00ed que simplemente lo dejamos en el aire, y no lo actualiza en absoluto. Pero, \u00bfqu\u00e9 ocurri\u00f3 aqu\u00ed? Tan pronto como 702 termin\u00f3 el proceso y 703 obtuvo su bloqueo, el sistema volvi\u00f3 atr\u00e1s. Y dijo que ahora tenemos dos personas que est\u00e1n en espera. Y luego actualicemos a ambos juntos. Y se\u00f1alemos que ambos est\u00e1n esperando. <\/p>\n
<\/p>\n
No s\u00e9 por qu\u00e9 Postgres hace esto. Pero hay un problema que se llama f.... Me parece que este no es un t\u00e9rmino en espa\u00f1ol. Es cuando todos esperan por un solo bloqueo, incluso si hay 20 instancias que est\u00e1n esperando el bloqueo. Y de repente, todos se despiertan al mismo tiempo. Y todos empiezan a intentar reaccionar. Pero el sistema hace que todos esperen 703. Porque todos est\u00e1n esperando, y los pondremos en cola de inmediato. Y si aparece cualquier otra nueva solicitud, que se hizo despu\u00e9s de eso, por ejemplo, 707, habr\u00e1 otra vez vac\u00edo. <\/p>\n
<\/p>\n
Y me parece que esto se hace para poder decir que en esta etapa 702 est\u00e1 esperando 703, y todos los que lleguen despu\u00e9s de esto no tendr\u00e1n ning\u00fan registro en este campo. Pero tan pronto como el primer en espera se va, todos los que estaban esperando en ese momento antes de la actualizaci\u00f3n obtienen el mismo marcador. Y por eso, me parece que esto se hizo para que pudi\u00e9ramos procesar en orden, para que estuvieran correctamente ordenados. <\/p>\n
<\/p>\n
Siempre he visto esto como un fen\u00f3meno bastante extra\u00f1o. Porque aqu\u00ed, por ejemplo, ni siquiera los enumeramos. Pero, me parece que cada vez que damos un nuevo bloqueo, miramos a todos los que est\u00e1n en proceso de espera. Entonces los alineamos en cola. Y luego, cualquier nuevo que llegue solo entra en la cola cuando la siguiente persona ha terminado de ser procesada. Muy buena pregunta. \u00a1Muchas gracias por la pregunta!<\/p>\n
<\/p>\n
Me parece mucho m\u00e1s l\u00f3gico que 705 espere a 704.<\/em> <\/p>\n<\/p>\n
Pero el problema aqu\u00ed es el siguiente. T t\u00e9cnicamente, puedes despertar uno u otro. Y por eso despertaremos uno u otro. Pero, \u00bfqu\u00e9 sucede en el funcionamiento del sistema? Ves c\u00f3mo el 703 en la parte superior bloque\u00f3 su propio ID de transacci\u00f3n. As\u00ed es como funciona Postgres. Y el 703 se bloquea con su propio ID de transacci\u00f3n, as\u00ed que si alguien quiere esperar, esperar\u00e1 al 703. Y, en esencia, el 703 finaliza. Y solo despu\u00e9s de que termine, alg\u00fan proceso se despierta. Y no sabemos cu\u00e1l de ellos ser\u00e1. Luego los procesamos gradualmente. Pero no est\u00e1 claro qu\u00e9 proceso se despierta primero, porque puede ser cualquiera de esos procesos. En esencia, ten\u00edamos un programador que dec\u00eda que ahora pod\u00edamos despertar cualquiera de esos procesos. Simplemente elegimos uno al azar. Por lo tanto, ambos deben ser marcados, porque podemos despertar cualquiera de ellos. <\/p>\n
<\/p>\n
Y el problema es que tenemos la CP-infinidad. Y por eso es bastante probable que podamos despertar uno m\u00e1s tard\u00edo. Y si, por ejemplo, estamos despertando uno m\u00e1s tard\u00edo, entonces estaremos esperando al que acaba de bloquearse, por lo que no determinamos qui\u00e9n ser\u00e1 despertado primero. Simplemente estamos creando esa situaci\u00f3n, y el sistema los despertar\u00e1 en un orden aleatorio. <\/p>\n
<\/p>\n
Hay art\u00edculos sobre locks de Yegor Rogov<\/a><\/noindex>. Mira, tambi\u00e9n son interesantes y \u00fatiles. El tema, por supuesto, es tremendamente complejo. \u00a1Muchas gracias, Bruce!<\/em><\/p>\nFuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2020 \u0433\u043e\u0434\u0430 \u0411\u0440\u044e\u0441\u0430 \u041c\u043e\u043c\u0436\u0438\u0430\u043d\u0430 "Unlocking the Postgres Lock Manager". (\u041f\u0440\u0438\u043c\u0435\u0447\u0430\u043d\u0438\u0435: \u0412\u0441\u0435 SQL \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438\u0437 \u0441\u043b\u0430\u0439\u0434\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043f\u043e \u044d\u0442\u043e\u0439 \u0441\u0441\u044b\u043b\u043a\u0435: http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql) \u041f\u0440\u0438\u0432\u0435\u0442! \u0417\u0430\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u043e\u0432\u0430 \u0431\u044b\u0442\u044c \u0437\u0434\u0435\u0441\u044c \u0432 \u0420\u043e\u0441\u0441\u0438\u0438. \u042f \u043f\u0440\u043e\u0448\u0443 \u043f\u0440\u043e\u0449\u0435\u043d\u0438\u0435, \u0447\u0442\u043e \u044f \u043d\u0435 \u0441\u043c\u043e\u0433 \u043f\u0440\u0438\u0435\u0445\u0430\u0442\u044c \u0432 \u043f\u0440\u043e\u0448\u043b\u043e\u043c \u0433\u043e\u0434\u0443, \u043d\u043e \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0443 \u0418\u0432\u0430\u043d\u0430 \u0438 \u0443 \u043c\u0435\u043d\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043f\u043b\u0430\u043d\u044b. \u042f, \u043d\u0430\u0434\u0435\u044e\u0441\u044c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":87955,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87954","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Desbloqueando](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n