Nabuo ang mga corrective update para sa lahat ng sinusuportahang branch ng PostgreSQL: 14.2, 13.6, 12.10, 11.15 at 10.20, na nagwawasto sa 55 error na natukoy sa nakalipas na tatlong buwan. Sa iba pang mga bagay, naayos namin ang mga problema na, sa mga bihirang pagkakataon, ay humantong sa index corruption kapag nagpapalit ng HOT (heap-only tuple) na chain sa panahon ng operasyon ng VACUUM o kapag nagsasagawa ng REINDEX CONCURRENTLY na operasyon sa mga index sa mga talahanayan na gumagamit ng TOAST storage mechanism.
Inayos ang mga pag-crash kapag nagsasagawa ng ALTER STATISTICS at kapag kumukuha ng data na may mga uri ng multirange. Naayos na ang mga bug sa query planner na nagdulot ng mga maling resulta. Ang mga naayos na memorya ay tumagas kapag nag-a-update ng mga index gamit ang mga expression at kapag nagsasagawa ng isang REASSIGN NA PAG-AARI NG operasyon sa isang malaking bilang ng mga bagay. Ang pagbuo ng mga advanced na istatistika para sa mga naka-segment na talahanayan ay ibinigay.
Bukod pa rito, maaari naming tandaan ang paglabas ng reshape utility, na nagbibigay-daan sa iyong magsagawa ng mga kumplikadong update sa data schema sa PostgreSQL nang hindi humihinto sa trabaho, na sa ilalim ng normal na mga kondisyon ay nangangailangan ng mga manu-manong pagbabago at pansamantalang pagsara ng mga serbisyo gamit ang database. Ginagawang posible ng utility na lumipat mula sa lumang scheme ng data patungo sa bago nang walang mahabang pagharang at nang hindi nakakaabala sa ikot ng pagproseso ng kahilingan. Awtomatikong gumagawa ang utility ng mga view ng talahanayan kung saan patuloy na gumagana ang mga application sa panahon ng paglilipat ng schema ng data, at nagko-configure din ng mga trigger na nagsasalin ng mga operasyon ng pagdaragdag at pagtanggal ng data sa pagitan ng luma at bagong mga schema.
Kaya, kapag gumagamit ng reshape sa panahon ng migration, ang luma at bagong schema ay mananatiling available sa parehong oras at ang mga application ay maaaring unti-unting ilipat sa bagong schema nang hindi humihinto sa trabaho (sa malalaking imprastraktura, ang mga humahawak ay maaaring unti-unting palitan mula sa luma hanggang sa bago). Kapag nakumpleto na ang paglipat ng mga application sa bagong schema, tatanggalin ang mga view at trigger na ginawa upang mapanatili ang suporta para sa lumang schema. Kung natukoy ang mga problema sa mga application sa panahon ng paglilipat, maaari mong baligtarin ang pagbabago ng schema at ibalik sa lumang estado.
Pinagmulan: opennet.ru