Sono stati generati aggiornamenti correttivi per tutti i rami supportati di PostgreSQL: 14.2, 13.6, 12.10, 11.15 e 10.20, che correggono 55 errori identificati negli ultimi tre mesi. Tra le altre cose, abbiamo risolto problemi che, in rare circostanze, portavano alla corruzione dell'indice quando si modificavano catene HOT (tuple solo heap) durante un'operazione VACUUM o quando si eseguiva un'operazione REINDEX CONCORRENTLY su indici su tabelle che utilizzano il meccanismo di archiviazione TOAST.
Risolti i crash durante l'esecuzione di ALTER STATISTICS e durante il recupero di dati con tipi multirange. I bug nel pianificatore di query che causavano risultati errati sono stati risolti. Risolte le perdite di memoria durante l'aggiornamento degli indici utilizzando le espressioni e durante l'esecuzione di un'operazione REASSIGN OWNED BY su un numero elevato di oggetti. È prevista la costruzione di statistiche avanzate per tabelle segmentate.
Inoltre, possiamo notare il rilascio dell'utilità di rimodellamento, che consente di eseguire aggiornamenti complessi allo schema dei dati in PostgreSQL senza interrompere il lavoro, che in condizioni normali richiede modifiche manuali e arresto temporaneo dei servizi che utilizzano il database. L'utility consente di passare dal vecchio schema dati a quello nuovo senza lunghi blocchi e senza interrompere il ciclo di elaborazione della richiesta. L'utilità crea automaticamente visualizzazioni tabella con cui le applicazioni continuano a lavorare durante la migrazione dello schema dei dati e configura inoltre trigger che traducono le operazioni di aggiunta ed eliminazione di dati tra il vecchio e il nuovo schema.
Pertanto, quando si utilizza il reshape durante la migrazione, il vecchio e il nuovo schema rimangono disponibili contemporaneamente e le applicazioni possono essere gradualmente trasferite nel nuovo schema senza interrompere il lavoro (nelle grandi infrastrutture, i gestori possono essere gradualmente sostituiti dal vecchio al nuovo). Una volta completata la migrazione delle applicazioni al nuovo schema, le visualizzazioni e i trigger creati per mantenere il supporto per il vecchio schema vengono eliminati. Se durante la migrazione vengono identificati problemi con le applicazioni, è possibile annullare la modifica dello schema e ripristinare lo stato precedente.
Fonte: opennet.ru