Después de haber discutido los problemas de aislamiento y haber hecho una digresión sobre la estructura de datos de bajo nivel , la última vez exploramos las versiones de fila y observamos cómo las diferentes operaciones cambiaron los campos de encabezado de tupla.

Ahora veremos cómo se obtienen instantáneas de datos consistentes de las tuplas.

¿Qué es una instantánea de datos?

Las páginas de datos pueden contener físicamente varias versiones de la misma fila. Pero cada transacción debe ver solo una versión (o ninguna) de cada fila, de modo que todas ellas constituyan una imagen coherente de los datos (en el sentido de ACID) a partir de un cierto punto en el tiempo.

El aislamiento en PosgreSQL se basa en instantáneas: cada transacción funciona con su propia instantánea de datos, que "contiene" datos que se confirmaron antes del momento en que se creó la instantánea y no "contiene" datos que aún no se confirmaron en ese momento. Ya hemos visto que, aunque el aislamiento resultante parece más estricto de lo requerido por el estándar, todavía tiene anomalías.

En el nivel de aislamiento de lectura confirmada, se crea una instantánea al comienzo de cada declaración de transacción. Esta instantánea está activa mientras se realiza la declaración. En la figura, el momento en que se creó la instantánea (que, como recordamos, está determinada por el ID de la transacción) se muestra en azul.



En los niveles de Lectura repetible y Serializable, la instantánea se crea una vez, al comienzo de la primera declaración de transacción. Dicha instantánea permanece activa hasta el final de la transacción.

Visibilidad de tuplas en una instantánea

Reglas de visibilidad

Una instantánea ciertamente no es una copia física de todas las tuplas necesarias. Una instantánea está realmente especificada por varios números, y la visibilidad de las tuplas en una instantánea está determinada por las reglas.

Si una tupla será visible o no en una instantánea depende de dos campos en el encabezado, a saber, xmin y xmax , es decir, los ID de las transacciones que crearon y eliminaron la tupla. Los intervalos como este no se superponen y, por lo tanto, no más de una versión representa una fila en cada instantánea.

Las reglas de visibilidad exactas son bastante complicadas y tienen en cuenta muchos casos diferentes y extremos.

Puede asegurarse fácilmente de eso mirando src / backend / utils / time / tqual.c (en la versión 12, la verificación se movió a src / backend / access / heap / heapam_visibility.c).

Para simplificar, podemos decir que una tupla es visible cuando en la instantánea, los cambios realizados por la transacción xmin son visibles, mientras que los realizados por la transacción xmax no lo son (en otras palabras, ya está claro que la tupla fue creada, pero aún no está claro si se eliminó).

Con respecto a una transacción, sus cambios son visibles en la instantánea, ya sea si esa misma transacción creó la instantánea (sí ve sus propios cambios aún no confirmados) o si la transacción se confirmó antes de que se creara la instantánea.

Podemos representar gráficamente las transacciones por segmentos (desde la hora de inicio hasta la hora de confirmación):



Aquí:

• Los cambios de la transacción 2 serán visibles ya que se completó antes de que se creara la instantánea.
• Los cambios de la transacción 1 no serán visibles ya que estaba activa en el momento en que se creó la instantánea.
• Los cambios de la transacción 3 no serán visibles desde que comenzó después de que se creó la instantánea (independientemente de si se completó o no).

Desafortunadamente, el sistema desconoce el tiempo de confirmación de las transacciones. Solo se conoce su hora de inicio (que está determinada por el ID de la transacción y marcada con una línea discontinua en las figuras anteriores), pero el evento de finalización no se escribe en ninguna parte.

Todo lo que podemos hacer es averiguar el estado actual de las transacciones en la creación de la instantánea. Esta información está disponible en la memoria compartida del servidor, en la estructura ProcArray, que contiene la lista de todas las sesiones activas y sus transacciones.

Sin embargo, no podremos determinar si existe una transacción activa en el momento en que se creó la instantánea. Por lo tanto, una instantánea tiene que almacenar una lista de todas las transacciones activas actuales.

De lo anterior se deduce que en PostgreSQL, no es posible crear una instantánea que muestre datos consistentes a partir de cierto tiempo hacia atrás, incluso si todas las tuplas necesarias están disponibles en las páginas de la tabla. A menudo surge una pregunta de por qué PostgreSQL carece de consultas retrospectivas (o temporales; o flashback, como las llama Oracle), y esta es una de las razones.

Algo gracioso es que esta funcionalidad estuvo disponible por primera vez, pero luego se eliminó del DBMS. Puedes leer sobre esto en el artículo de Joseph M. Hellerstein .

Entonces, la instantánea está determinada por varios parámetros:

• En el momento en que se creó la instantánea, más exactamente, el ID de la próxima transacción, aún no disponible en el sistema ( snapshot.xmax ).
• La lista de transacciones activas (en progreso) en el momento en que se creó la snapshot.xip ( snapshot.xip ).

Por conveniencia y optimización, el ID de la primera transacción activa también se almacena ( snapshot.xmin ). Este valor tiene un sentido importante, que se discutirá a continuación.

Sin embargo, la instantánea también almacena algunos parámetros más, que no son importantes para nosotros.

Ejemplo

Para comprender cómo la instantánea determina la visibilidad, reproduzcamos el ejemplo anterior con tres transacciones. La tabla tendrá tres filas, donde:

• El primero fue agregado por una transacción que comenzó antes de la creación de la instantánea pero que se completó después.
• El segundo fue agregado por una transacción que comenzó y se completó antes de la creación de la instantánea.
• El tercero se agregó después de la creación de la instantánea.

 => TRUNCATE TABLE accounts; 

La primera transacción (aún no completada):

 => BEGIN; => INSERT INTO accounts VALUES (1, '1001', 'alice', 1000.00); => SELECT txid_current(); 

 => SELECT txid_current(); txid_current -------------- 3695 (1 row) 

La segunda transacción (completada antes de que se creara la instantánea):

 | => BEGIN; | => INSERT INTO accounts VALUES (2, '2001', 'bob', 100.00); | => SELECT txid_current(); 

 | txid_current | -------------- | 3696 | (1 row) 

 | => COMMIT; 

Crear una instantánea en una transacción en otra sesión.

 || => BEGIN ISOLATION LEVEL REPEATABLE READ; || => SELECT xmin, xmax, * FROM accounts; 

 || xmin | xmax | id | number | client | amount || ------+------+----+--------+--------+-------- || 3696 | 0 | 2 | 2001 | bob | 100.00 || (1 row) 

Confirmar la primera transacción después de que se creó la instantánea:

 => COMMIT; 

Y la tercera transacción (apareció después de que se creó la instantánea):

 | => BEGIN; | => INSERT INTO accounts VALUES (3, '2002', 'bob', 900.00); | => SELECT txid_current(); 

 | txid_current | -------------- | 3697 | (1 row) 

 | => COMMIT; 

Evidentemente, solo una fila sigue siendo visible en nuestra instantánea:

 || => SELECT xmin, xmax, * FROM accounts; 

 || xmin | xmax | id | number | client | amount || ------+------+----+--------+--------+-------- || 3696 | 0 | 2 | 2001 | bob | 100.00 || (1 row) 

La pregunta es cómo Postgres entiende esto.

Todo está determinado por la instantánea. Veámoslo:

 || => SELECT txid_current_snapshot(); 

 || txid_current_snapshot || ----------------------- || 3695:3697:3695 || (1 row) 

Aquí se enumeran snapshot.xmin , snapshot.xmax y snapshot.xip , delimitados por dos puntos ( snapshot.xip es un número en este caso, pero en general es una lista).

De acuerdo con las reglas anteriores, en la instantánea, esos cambios deben ser visibles que fueron realizados por transacciones con ID xid modo que snapshot.xmin <= xid < snapshot.xmax excepto aquellos que están en la lista snapshot.xip . Veamos todas las filas de la tabla (en la nueva instantánea):

 => SELECT xmin, xmax, * FROM accounts ORDER BY id; 

  xmin | xmax | id | number | client | amount ------+------+----+--------+--------+--------- 3695 | 0 | 1 | 1001 | alice | 1000.00 3696 | 0 | 2 | 2001 | bob | 100.00 3697 | 0 | 3 | 2002 | bob | 900.00 (3 rows) 

La primera fila no es visible: fue creada por una transacción que está en la lista de transacciones activas ( xip ).
La segunda fila es visible: fue creada por una transacción que está en el rango de instantáneas.
La tercera fila no es visible: fue creada por una transacción que está fuera del rango de la instantánea.

 || => COMMIT; 

Cambios propios de la transacción.

Determinar la visibilidad de los propios cambios de la transacción complica un poco la situación. En este caso, puede ser necesario ver solo una parte de dichos cambios. Por ejemplo: en cualquier nivel de aislamiento, un cursor abierto en un momento determinado no debe ver los cambios realizados más tarde.

Para este fin, un encabezado de tupla tiene un campo especial (representado en las pseudocolumnas cmin y cmax ), que muestra el número de orden dentro de la transacción. cmin es el número para la inserción, y cmax - para la eliminación, pero para ahorrar espacio en el encabezado de la tupla, este es en realidad un campo en lugar de dos diferentes. Se supone que una transacción inserta y elimina con poca frecuencia la misma fila.

Pero si esto sucede, se inserta un ID de comando combinado especial ( combocid ) en el mismo campo, y el proceso de fondo recuerda los cmin y cmax reales para este combocid . Pero esto es completamente exótico.

Aquí hay un ejemplo simple. Comencemos una transacción y agreguemos una fila a la tabla:

 => BEGIN; => SELECT txid_current(); 

  txid_current -------------- 3698 (1 row) 

 INSERT INTO accounts(id, number, client, amount) VALUES (4, 3001, 'charlie', 100.00); 

Vamos a mostrar el contenido de la tabla, junto con el campo cmin (pero solo para las filas agregadas por la transacción; para otros no tiene sentido):

 => SELECT xmin, CASE WHEN xmin = 3698 THEN cmin END cmin, * FROM accounts; 

  xmin | cmin | id | number | client | amount ------+------+----+--------+---------+--------- 3695 | | 1 | 1001 | alice | 1000.00 3696 | | 2 | 2001 | bob | 100.00 3697 | | 3 | 2002 | bob | 900.00 3698 | 0 | 4 | 3001 | charlie | 100.00 (4 rows) 

Ahora abrimos un cursor para una consulta que devuelve el número de filas en la tabla.

 => DECLARE c CURSOR FOR SELECT count(*) FROM accounts; 

Y después de eso agregamos otra fila:

 => INSERT INTO accounts(id, number, client, amount) VALUES (5, 3002, 'charlie', 200.00); 

La consulta devuelve 4: la fila agregada después de abrir el cursor no entra en la instantánea de datos:

 => FETCH c; 

  count ------- 4 (1 row) 

Por qué Porque la instantánea solo tiene en cuenta las tuplas con cmin < 1 .

 => SELECT xmin, CASE WHEN xmin = 3698 THEN cmin END cmin, * FROM accounts; 

  xmin | cmin | id | number | client | amount ------+------+----+--------+---------+--------- 3695 | | 1 | 1001 | alice | 1000.00 3696 | | 2 | 2001 | bob | 100.00 3697 | | 3 | 2002 | bob | 900.00 3698 | 0 | 4 | 3001 | charlie | 100.00 3698 | 1 | 5 | 3002 | charlie | 200.00 (5 rows) 

 => ROLLBACK; 

Horizonte de eventos

El ID de la primera transacción activa ( snapshot.xmin ) tiene un sentido importante: determina el "horizonte de eventos" de la transacción. Es decir, más allá de su horizonte, la transacción siempre ve solo versiones de fila actualizadas.

Realmente, una versión de fila desactualizada (inactiva) debe ser visible solo cuando la actualizada fue creada por una transacción aún no completada y, por lo tanto, aún no es visible. Pero todas las transacciones "más allá del horizonte" se completan con seguridad.



Puede ver el horizonte de transacciones en el catálogo del sistema:

 => BEGIN; => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

  backend_xmin -------------- 3699 (1 row) 

También podemos definir el horizonte a nivel de la base de datos. Para hacer esto, necesitamos tomar todas las instantáneas activas y encontrar las xmin más xmin entre ellas. Y definirá el horizonte, más allá del cual las tuplas muertas en la base de datos nunca serán visibles para ninguna transacción. Tales tuplas se pueden aspirar , y esta es exactamente la razón por la cual el concepto de horizonte es tan importante desde un punto de vista práctico.

Si una determinada transacción retiene una instantánea durante mucho tiempo, también mantendrá el horizonte de la base de datos. Además, solo la existencia de una transacción incompleta mantendrá el horizonte incluso si la transacción en sí no contiene la instantánea.

Y esto significa que las tuplas muertas en el DB no se pueden aspirar. Además, es posible que una transacción de "larga duración" no se cruce con los datos con otras transacciones, pero esto realmente no importa ya que todos comparten un horizonte de base de datos.

Si ahora hacemos que un segmento represente instantáneas (desde snapshot.xmin a snapshot.xmax ) en lugar de transacciones, podemos visualizar la situación de la siguiente manera:



En esta figura, la instantánea más baja corresponde a una transacción incompleta, y en las otras instantáneas, snapshot.xmin no puede ser mayor que el ID de la transacción.

En nuestro ejemplo, la transacción se inició con el nivel de aislamiento de lectura confirmada. Aunque no tiene ninguna instantánea de datos activa, sigue manteniendo el horizonte:

 | => BEGIN; | => UPDATE accounts SET amount = amount + 1.00; | => COMMIT; 

 => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

  backend_xmin -------------- 3699 (1 row) 

Y solo después de la finalización de la transacción, el horizonte avanza, lo que permite aspirar las tuplas muertas:

 => COMMIT; => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

  backend_xmin -------------- 3700 (1 row) 

En el caso de que la situación descrita realmente cause problemas y no haya forma de solucionarlo a nivel de aplicación, hay dos parámetros disponibles a partir de la versión 9.6:

• old_snapshot_threshold determina la vida útil máxima de la instantánea. Cuando transcurra este tiempo, el servidor será elegible para aspirar tuplas muertas, y si una transacción de "larga duración" aún las necesita, obtendrá un error "instantánea demasiado antigua".
• idle_in_transaction_session_timeout determina la vida útil máxima de una transacción inactiva. Cuando transcurre este tiempo, la transacción se cancela.

Exportación de instantáneas

A veces surgen situaciones en las que se debe garantizar que varias transacciones concurrentes vean los mismos datos. Un ejemplo es una utilidad pg_dump , que puede funcionar en modo paralelo: todos los procesos de trabajo deben ver la base de datos en el mismo estado para que la copia de seguridad sea coherente.

Por supuesto, no podemos confiar en la creencia de que las transacciones verán los mismos datos solo porque se iniciaron "simultáneamente". Para este fin, la exportación e importación de una instantánea están disponibles.

La función pg_export_snapshot devuelve el ID de la instantánea, que se puede pasar a otra transacción (usando herramientas fuera del DBMS).

 => BEGIN ISOLATION LEVEL REPEATABLE READ; => SELECT count(*) FROM accounts; -- any query 

  count ------- 3 (1 row) 

 => SELECT pg_export_snapshot(); 

  pg_export_snapshot --------------------- 00000004-00000E7B-1 (1 row) 

La otra transacción puede importar la instantánea utilizando el comando SET TRANSACTION SNAPSHOT antes de realizar su primera consulta. El nivel de aislamiento de lectura repetible o serializable también debe especificarse antes, ya que en el nivel de confirmación de lectura, las declaraciones utilizarán sus propias instantáneas.

 | => DELETE FROM accounts; | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SET TRANSACTION SNAPSHOT '00000004-00000E7B-1'; 

La segunda transacción ahora funcionará con la instantánea de la primera y, por lo tanto, verá tres filas (en lugar de cero):

 | => SELECT count(*) FROM accounts; 

 | count | ------- | 3 | (1 row) 

La duración de una instantánea exportada es la misma que la duración de la transacción de exportación.

 | => COMMIT; => COMMIT; 

Sigue leyendo .