Se han creado actualizaciones correctivas para todas las ramas compatibles de PostgreSQL: 14.2, 13.6, 12.10, 11.15 y 10.20, en las que se han corregido 55 errores detectados en los últimos tres meses. Entre ellos, se han solucionado problemas que, en raras circunstancias, podían provocar la corrupción de índices al modificar cadenas HOT (heap-only tuple) durante la operación VACUUM o al ejecutar la operación REINDEX CONCURRENTLY en índices de tablas que utilizan el mecanismo de almacenamiento TOAST.
Se han solucionado cierres inesperados al ejecutar ALTER STATISTICS y al extraer datos con tipos multirango. En el planificador de consultas se han corregido errores que daban como resultado resultados incorrectos. Se han eliminado fugas de memoria al actualizar índices basados en expresiones y al realizar la operación 'REASSIGN OWNED BY' sobre un gran número de objetos. Se ha asegurado la construcción de estadísticas avanzadas para tablas segmentadas.
También se puede señalar el lanzamiento de la herramienta reshape, que permite realizar actualizaciones complejas en el esquema de datos en PostgreSQL sin detener el funcionamiento, lo que normalmente requeriría cambios manuales y detener temporalmente los servicios que utilizan la base de datos. La herramienta permite la transición de un viejo esquema de datos a uno nuevo sin bloqueos prolongados y sin interrumpir el ciclo de procesamiento de consultas. La herramienta crea automáticamente vistas de tablas, con las que las aplicaciones continúan trabajando durante la migración del esquema de datos, y también configura desencadenadores que traducen las operaciones de adición y eliminación de datos entre el viejo y el nuevo esquema.
Así, al utilizar reshape durante la migración, el viejo y el nuevo esquema permanecen accesibles al mismo tiempo y las aplicaciones se pueden transferir gradualmente al nuevo esquema sin detener su funcionamiento (en grandes infraestructuras se pueden reemplazar los controladores antiguos por nuevos de manera progresiva). Una vez que se ha completado la transición de las aplicaciones al nuevo esquema, las vistas y desencadenadores creados para mantener la compatibilidad con el viejo esquema se eliminan. En caso de detectar problemas con las aplicaciones durante la migración, se puede revertir el cambio de esquema y volver al estado anterior.
Fuente: opennet.ru
