PostgreSQL 15.1

Szczęśliwego nowego PostgreSQL! Noworoczne informacje dotyczące wersji 15.1 i poprzedniczek

Pod koniec 2022 roku otrzymaliśmy od zespołu Postgresa szereg nowych uaktualnień, które poprawiają jakość i bezpieczeństwo naszych baz danych. W tym artykule przyjrzymy się dokładniej ostatnim poprawkom PostgreSQL, wymienimy wersje, które otrzymały patche, a dla których jest to ostatnia oficjalna łatka.

Pod koniec 2022 roku otrzymaliśmy od zespołu Postgresa szereg nowych uaktualnień, które poprawiają jakość i bezpieczeństwo naszych baz danych. Dziś przyjrzymy się dokładniej ostatnim poprawkom PostgreSQL, wymienimy wersje, które otrzymały patche, a dla których jest to ostatnia oficjalna łatka. Zapraszamy do lektury.

Zespół inżynierów PostgreSQL cały czas pozytywnie zaskakuje szybkością wydawania poprawek i łatek dla ich produktu. Po wydaniu wyczekiwanej 15 wersji Postgresa i jej ciepłym przyjęciu przez użytkowników, twórcy nie spoczęli na laurach. Już niespełna miesiąc później, bo 10 listopada 2022, otrzymaliśmy spory patch poprawek dla różnych wersji systemu bazodanowego Postgres. Wsparcie zespołu deweloperów PostgreSQL obejmuje jedynie najświeższe wersje bazy danych, stąd poprawki są dostępne dla następujących wersji: 15.1, 14.6, 13.9, 12.13, 11.18, i 10.23.

Najlepszy czas na zmiany

Należy podkreślić, że wsparcie dla wersji 10 Postgresa dobiegło końca. Jak sami twórcy podkreślają: „PostgreSQL 10 nie będzie dłużej otrzymywał poprawek i łatek bezpieczeństwa”. Postgres 10.23 jest więc finalną formą produktu w wersji 10 i zaleca się przejście na wyższe wersje. Aby dowiedzieć się więcej na temat podnoszenia wersji PostgreSQL na nowszą, zalecamy zapoznać się z wbudowanym narzędziem pg_upgrade. Dokumentacja dostępna jest tutaj.

Szczegółowy opis poprawek

Oto lista i opis poprawek które zostały przygotowane dla wersji 15.1. Jednak niektóre z nich są również dostarczono dla poprzednich wersji PostgreSQL, w tym także dla wydania 10.23.

Zmiana Dodatkowe informacje Autor/Autorzy
Naprawiono błąd usuwania segmentów dużych tabel. Osierocone tablice tymczasowe są usuwane podczas startu postmastera, więc aktualizacja do wersji 15.1 wystarczy, aby je wyczyścić. Jednak, jeżeli miałeś jakiekolwiek awarie bazy danych podczas używania 15.0, a zrzucane tablice były duże, warto sprawdzić katalogi bazy danych dla plików nazwanych według wzoru NNNN.NN. Jeżeli pliki nie pasują do wzorca i mają nazwę NNNN (bez końcówki .NN), powinny zostać usunięte ręcznie. Tom Lane
Poprawiono obsługę tokenów DEFAULT, które pojawiają się w wielowierszowej klauzuli VALUES polecenia INSERT w aktualizowanym widoku. To niedopatrzenie mogło prowadzić do błędów typu „cache lookup failed for type”, a w starszych gałęziach nawet do błędu krytycznego. Tom Lane
Usunięto reguły o nazwie _RETURN, które nie są ON SELECT. Pozwala to uniknąć pomylenia reguł ON SELECT w widoku z innymi regułami. Tom Lane
Poprawiono EXPLAIN VERBOSE dla zapytania wykorzystującego SEARCH BREADTH FIRST ze stałymi wartościami początkowymi. Tom Lane
Zlikwidowano użycie MERGE na tabeli partycjonowanej z partycjami tabel obcych. Jest to nieobsługiwane, wcześniej zwracany był niezrozumiały błąd. Álvaro Herrera
Poprawiono tworzenie ograniczeń klucza obcego dla partycji podczas wykonywania ALTER TABLE ATTACH PARTITION. Poprzednio mogły zostać utworzone nieprawidłowe lub zduplikowane ograniczenia dla nowo dodanej partycji. Jehan-Guillaume de Rorthais, Álvaro Herrera
Naprawiono błąd planisty z rozszerzonymi statystykami na partycjonowanych lub dziedziczonych tabelach. W niektórych przypadkach występował błąd „cache lookup failed for statistics object”. Richard Guo, Justin Pryzby
Poprawiono błędną kolejność operacji WAL w ścieżce szybkiego uruchomienia dla indeksów GIN. Błąd ten nie ma żadnych negatywnych konsekwencji w rdzeniu PostgreSQL, ale powodował problemy w niektórych rozszerzeniach. Matthias van de Meent, Zhang Mingli
Naprawiono błędy w dekodowaniu logicznym, gdy odtwarzanie rozpoczynało się od punktu pomiędzy początkiem transakcji a początkiem jej podtransakcji. Mogło to prowadzić do błędów asercji w debugowanych kompilacjach, a w innych przypadkach do wycieków pamięci. Masahiko Sawada, Kuroda Hayato
Poprawiono aspekty przerwania pracy w większej ilości miejsc podczas dekodowania logicznego. Niweluje to problemy z powolnym zamykaniem workerów replikacji. Amit Kapila, Masahiko Sawada
Uniemożliwiono replikację partycji tabeli obcej. Mimo że tabele partycjonowane mogą mieć tabele obce jako partycje, replikacja na taką partycję nie jest obecnie obsługiwana. Proces workera replikacji logicznej uległby awarii. Obecnie wyświetlany jest błąd. Shi Yu, Tom Lane
Poprawiono zachowanie po błędzie składni funkcji w pracach replikacyjnych. Jeżeli wystąpiłby błąd składni w poleceniu CREATE FUNCTION lub DO w języku SQL lub PL/pgSQL, proces workera napotakałby błąd z dereferencją wskaźnika null lub niepowodzeniem asercji. Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane
Uniemożliwiono wykonanie podwójnego wywołania zwrotnego zamknięcia modułu archiwizującego. Nathan Bossart, Bharath Rupireddy
Dodano sprawdzanie w czasie rzeczywistym próby dostępu do tabeli, która nie ma metody dostępu. Zapobiega to awarii, a w niektórych scenariuszach uszkodzenia katalogu, na przykład przy użyciu widoku, w którym brakuje reguły ON SELECT. Tom Lane
Naprawiono awarię postmastera, gdy stan pamięci współdzielonej jest uszkodzony. Jeżeli pamięć współdzielona zostanie uszkodzona, proces postmastera powinien zainicjować restart bazy danych. Tom Lane
Poprawiono obsługę trybu single-row w libpq. Flaga single-row nie była resetowana w prawidłowym czasie, gdy tryb potokowy był aktywny. Denis Laxalde
Naprawiono status wyjścia psql, gdy zapytanie z linii poleceń jest anulowane. psql -c query zwraca pomyślny status wyjścia, nawet jeżeli zapytanie zostało anulowane. Poprawiono to, aby w takich przypadkach status wyjścia psql był niezerowy. Peter Eisentraut
Umożliwiono międzyplatformową relokację przestrzeni tabel w pg_basebackup. Zezwolono, aby zdalna ścieżka w –tablespace-mapping była ścieżką absolutną w stylu Unix lub Windows, ponieważ serwer źródłowy może być na innym systemie operacyjnym niż lokalny. Robert Haas
Naprawiono błąd pg_dump przy komentarzach dołączonych do CHECK. Tom Lane
Poprawiono CREATE DATABASE, aby umożliwić parametrowi OID przekroczenie numeru 231. To niedopatrzenie uniemożliwiało poprawne wykonanie pg_upgrade, gdy instalacja źródłowa zawierała bazy danych z OID większymi niż 231. Tom Lane
Poprawiono dostęp do zwolnionej pamięci w pg_stat_statements. Problem ten występował, gdy pg_stat_statements śledziło polecenie ROLLBACK wydane przez rozszerzony protokół zapytań. zhaoqigui
Naprawiono niezgodności z LLVM 15. Thomas Munro, Andres Freund
Umożliwiono użycie __sync_lock_test_and_set() dla spinlocków na dowolnej maszynie. Ułatwi to portowanie na nowe architektury maszyn, przynajmniej w przypadku używania kompilatora, który obsługuje tę wbudowaną funkcję GCC. Tom Lane
Tom Lane
Zmieniono sposób używania sprintf, aby zniwelować ostrzeżenia dotyczące „compile-time deprecation”. Tom Lane

Oprócz powyższej tabeli ulepszeń wraz z ich szczegółowym opisem poprawiono nazewnictwo stref czasowych zgodnie z tzdata z 2022 roku. Zmieniono także nazwę strefy Europe/Kiev na Europe/Kyiv. Oprócz tego następujące strefy zostały połączone z pobliskimi, większymi strefami, które mają tę samą godzinę od 1970 roku. Są to:

Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake, Pacific/Wallis.

Należy podkreślić, że wszystkie obecnie używane nazwy stref czasowych będą dostępne jako alias do nowo nadanych.

Podsumowanie

Obserwując od dłuższego czasu zespół inżynierów The PostgreSQL Global Development Group możemy być spokojni o przyszłość Postgresa. Wraz z tworzeniem nowych wersji systemu bazodanowego, jesteśmy w stanie w bardziej wydajny i coraz bezpieczniejszy sposób administrować bazą danych. Wszystkie osoby, którym nie wystarczają możliwości „czystego” PosgtreSQL, zachęcamy do zapoznania się z platformą bazodanową EuroDB, która znacząco rozszerza możliwości Postgresa i jednocześnie jest z nim w pełni kompatybilna.

Autorzy

The blog articles are written by people from the EuroLinux team. We owe 80% of the content to our developers, the rest is prepared by the sales or marketing department. We make every effort to ensure that the content is the best in terms of content and language, but we are not infallible. If you see anything that needs to be corrected or clarified, we'd love to hear from you.