Sono stati creati aggiornamenti correttivi per tutti i rami supportati di PostgreSQL: 14.2, 13.6, 12.10, 11.15 e 10.20, nei quali sono stati corretti 55 errori rilevati negli ultimi tre mesi. Sono stati risolti problemi che, in circostanze rare, portavano alla 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 eliminati i crash durante l'esecuzione di ALTER STATISTICS e durante il recupero di dati con tipi multirange. Nel pianificatore delle query sono stati risolti errori che portavano a risultati non corretti. Sono state eliminate 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. È stato garantito un costruttore di statistiche avanzate per le tabelle segmentate.
Inoltre, si può notare il rilascio dell'utilità reshape, che consente di effettuare aggiornamenti complessi dello schema dei dati in PostgreSQL senza arrestare il funzionamento, normalmente richiederebbe modifiche manuali e un'interruzione temporanea dei servizi che utilizzano il DB. L'utilità permette di passare da un vecchio schema dei dati a uno nuovo senza lunghe interruzioni e senza interrompere il ciclo di elaborazione delle richieste. L'utilità crea automaticamente le viste delle tabelle con cui le applicazioni continuano a lavorare durante la migrazione dello schema dei dati, e configura anche i trigger che trasmettono operazioni di aggiunta e rimozione di dati tra il vecchio e il nuovo schema.
Pertanto, utilizzando reshape durante la migrazione, il vecchio e il nuovo schema rimangono contemporaneamente accessibili e le applicazioni possono essere gradualmente trasferite al nuovo schema senza interrompere il funzionamento (nelle grandi infrastrutture è possibile sostituire gradualmente i gestori da uno vecchio a uno nuovo). Dopo aver completato il trasferimento delle applicazioni al nuovo schema, le viste e i trigger creati per garantire il supporto del vecchio schema vengono eliminati. In caso di problemi con le applicazioni durante la migrazione, è possibile annullare la modifica dello schema e tornare allo stato precedente.
Fonte: opennet.ru
