{"id":103298,"date":"2022-02-11T15:36:48","date_gmt":"2022-02-11T13:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/obnovlenie-postgresql-vypusk-reshape-utility-dlya-migraczii-na-novuyu-shemu-bez-ostanovki-raboty"},"modified":"2022-02-11T15:36:48","modified_gmt":"2022-02-11T13:36:48","slug":"obnovlenie-postgresql-vypusk-reshape-utility-dlya-migraczii-na-novuyu-shemu-bez-ostanovki-raboty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/obnovlenie-postgresql-vypusk-reshape-utility-dlya-migraczii-na-novuyu-shemu-bez-ostanovki-raboty","title":{"rendered":"Aggiornamento di PostgreSQL. Rilascio di reshape, un'utilit\u00e0 per la migrazione a un nuovo schema senza fermare il funzionamento.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
Risolti gli arresti anomali durante l'esecuzione di ALTER STATISTICS e durante l'estrazione dei dati con tipi multirange. Nel pianificatore delle query sono stati corrette le anomalie che portavano a risultati non corretti. Risolte perdite di memoria durante l'aggiornamento degli indici per espressioni e nell'esecuzione dell'operazione «REASSIGN OWNED BY» su un gran numero di oggetti. Garantita la costruzione di statistiche avanzate per tabelle segmentate. <\/p>\n
Inoltre, si pu\u00f2 notare il rilascio dell'utilit\u00e0 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\u00e0 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\u00e0 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. <\/p>\n
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 \u00e8 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, \u00e8 possibile annullare la modifica dello schema e tornare allo stato precedente. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"