Statisticile PostgreSQL 18 nu încheie actualizarea

O actualizare poate porni cu succes noua bază de date, lăsând totuși neterminate verificări importante de acceptare. PostgreSQL 18 reduce o sursă de perturbare prin păstrarea statisticilor optimizatorului la pg_upgrade. Îmbunătățirea merită folosită fără a o trata drept dovadă că setările sumelor de control, refacerile necesare sau comportamentul interogărilor aplicației sunt deja rezolvate. Planificați actualizarea în jurul unui serviciu utilizabil, nu al primei porniri reușite a serverului.

Privind din noiembrie 2026, PostgreSQL 18 a fost anunțat pe 25 septembrie 2025. Notele versiunii 18 dau aceeași dată și includ păstrarea statisticilor printre schimbările principale. Sunt fapte despre versiunea stabilă. Diferă de discuțiile anterioare de testare despre skip scan și coloane generate, care privesc alegerea mecanismelor de interogare și de schemă, nu acceptarea actualizării unei instalări existente.

Statisticile descriu distribuții ale datelor folosite la alegerea planurilor. Transferul informației utile peste o actualizare poate reduce perioada în care noul server nu dispune de ea. Nu fixează optimizatorul și nu promite același plan pentru fiecare interogare. O versiune majoră nouă poate lua alte decizii chiar când pornește cu informații statistice familiare.

Manualul pg_upgrade pentru versiunea majoră 18, consultat în noiembrie 2026, spune că majoritatea statisticilor optimizatorului se transferă dacă nu se specifică --no-statistics. Exclude explicit statisticile create cu CREATE STATISTICS, statisticile personalizate adăugate de extensii și statisticile colectate de sistemul de statistici cumulative. Este documentație versionată întreținută, nu o copie înghețată a paginii din ziua lansării. Precizarea împiedică transformarea afirmației „statisticile se păstrează” în „toate statisticile supraviețuiesc neschimbate”.

Pentru echipa operațională, distincția schimbă programul de după actualizare. Există mai puține motive să presupună că fiecare relație pornește fără statistici obișnuite ale optimizatorului, dar rămâne motivul de a urma instrucțiunile uneltei pentru informația lipsă. Tratați acele instrucțiuni ca parte din rezultatul instalării concrete. Un articol general nu poate determina ce extensii sau obiecte statistice conține clusterul dumneavoastră.

Opțiunea implicită nouă nu descrie clusterul vechi

Notele versiunii spun că initdb activează acum implicit sumele de control ale datelor. Spun și că pg_upgrade cere setări identice ale sumelor de control între clustere. Un cluster vechi fără sume de control nu le dobândește doar fiindcă destinația a fost inițializată cu PostgreSQL 18. Noua opțiune implicită și starea existentă sunt două fapte separate care trebuie puse de acord înainte să poată continua actualizarea.

Aceleași note identifică --no-data-checksums ca opțiune de inițializare utilă unei destinații care corespunde unei surse fără sume de control. Este o opțiune documentată de compatibilitate, nu o instrucțiune de a dezactiva aici protecția unei baze de date în funcțiune. Decizia potrivită depinde de planul migrării, starea verificată a sursei și procedura operațională autorizată. Pentru articol nu s-au schimbat setări sau fișiere de baze de date.

De aceea, inventarul ar trebui să consemneze starea, nu doar numerele versiunilor. Două instalări cu aceeași versiune majoră veche pot avea istorii diferite de inițializare. Un plan copiat de la una poate eșua pentru cealaltă, chiar dacă ambele funcționează normal. Înregistrați observațiile despre sursă și ce trebuie să corespundă la destinație, cu un responsabil pentru rezolvarea diferențelor.

Refacerile necesare preced acceptarea

Manualul pg_upgrade spune că generează scripturi pentru procesarea necesară după actualizare și avertizează că accesarea tabelelor numite în scripturile de refacere înainte de finalizarea lor poate produce rezultate incorecte sau performanță slabă. Un server care acceptă conexiuni nu poate fi, așadar, singurul criteriu de încheiere. Citiți rezultatul specific instalării și îndepliniți obligațiile înainte să tratați traseele afectate ale datelor ca pregătite.

Notele versiunii oferă alt exemplu delimitat: pentru clustere al căror furnizor implicit de collation diferit de libc se comportă altfel decât libc la prelucrarea relevantă a caracterelor, se recomandă refacerea indexurilor legate de căutarea în text integral și pg_trgm după pg_upgrade. Păstrați condiția și forța recomandării. Nu este o obligație universală de a reface fiecare index și nici permisiunea de a ignora un script efectiv de refacere.

Alegerile de transfer al fișierelor sunt o decizie separată de recuperare. Manualul versiunii 18 avertizează că modul link poate partaja fișiere între clusterele vechi și noi; după ce noul cluster pornește și scrie în ele, reutilizarea celui vechi este nesigură fără restaurarea din backup. Economia de timp la transfer nu dovedește existența unei copii independente pentru revenire. Articolul nu oferă comenzi de migrare și nu efectuează transferuri, actualizări sau exerciții de recuperare a bazelor de date.

Acceptarea ar trebui să urmeze interogările importante

Un set propus de acceptare ar trebui să includă interogările de care depind clienții sau operatorii, cu parametri și distribuții ale datelor reprezentative. Verificați rezultatele returnate, durata și planurile. Schimbarea unui plan este o observație de înțeles, nu automat o regresie. Un rezultat rapid cu alt sens pentru afacere înseamnă acceptare eșuată, chiar dacă baza de date nu raportează erori.

Păstrați comparația inteligibilă. Consemnați versiunile sursei și destinației, extensiile, configurația relevantă și dacă execuția privește o sarcină rece sau deja încălzită. Luați în calcul schimbările simultane ale aplicației. Sunt verificări propuse pentru un mediu autorizat; pentru articol nu s-au efectuat teste de interogări reprezentative, teste de performanță sau măsurători ale indisponibilității. Statisticile păstrate nu pot furniza observațiile lipsă.

Contraargumentul cel mai puternic este o bază de date mică pentru care exportul și restaurarea sunt mai ușor de înțeles și de repetat. Poate fi o alegere rezonabilă când costul operațional măsurat corespunde afacerii. Existența unui pg_upgrade mai bun nu îl face obligatoriu. Pentru dezvoltare software la comandă, alegeți metoda cu o cale explicită de recuperare și dovezi de acceptare. Folosiți statisticile păstrate pentru a reduce o perturbare, apoi încheiați verificările de compatibilitate și interogare care fac noul serviciu fiabil.