Sono stati creati aggiornamenti correttivi per tutti i rami supportati di PostgreSQL: 14.2, 13.6, 12.10, 11.15 e 10.20, che risolvono 55 errori identificati negli ultimi tre mesi. Questo include la risoluzione di problemi che, in rare circostanze, portavano a corruzione degli indici durante la modifica delle catene HOT (heap-only tuple) durante l'esecuzione dell'operazione VACUUM o durante l'esecuzione dell'operazione REINDEX CONCURRENTLY per indici su tabelle che utilizzano il meccanismo di archiviazione TOAST.
Sono stati risolti arresti anomali durante l'esecuzione di ALTER STATISTICS e durante l'estrazione di dati con tipi multirange. Nel pianificatore delle query sono stati corretti errori che portavano a risultati errati. Risolte perdite di memoria durante l'aggiornamento degli indici basati su espressioni e durante l'esecuzione dell'operazione «REASSIGN OWNED BY» su un gran numero di oggetti. È stata garantita la costruzione di statistiche avanzate per tabelle segmentate.
In aggiunta, è possibile evidenziare il rilascio dell'utilità reshape, che consente di effettuare aggiornamenti complessi allo schema dei dati in PostgreSQL senza interrompere il servizio. In condizioni normali, tali aggiornamenti richiederebbero modifiche manuali e un'interruzione temporanea dei servizi che utilizzano il database. L'utilità permette di passare da un vecchio schema dati a uno nuovo senza lunghe operazioni di blocco e senza interrompere il ciclo di elaborazione delle richieste. Inoltre, l'utilità crea automaticamente le viste delle tabelle, con cui le applicazioni continuano a lavorare durante la migrazione dello schema dei dati, e configura i trigger che trasmettono le operazioni di aggiunta e cancellazione di dati tra il vecchio e il nuovo schema.
In questo modo, utilizzando reshape durante la migrazione, il vecchio e il nuovo schema rimangono disponibili contemporaneamente, permettendo di migrare le applicazioni al nuovo schema senza interrompere le operazioni (nei grandi ambienti, i gestori possono essere sostituiti gradualmente da vecchi a nuovi). Una volta completata la migrazione delle applicazioni al nuovo schema, le viste e i trigger creati per supportare il vecchio schema vengono rimossi. In caso di problemi con le applicazioni durante la migrazione, è possibile annullare la modifica dello schema e tornare allo stato precedente.
Fonte: opennet.ru
