Jak sprawdzić aktualną wartość parametru i skąd pochodzi

PostgreSQL

Jak sprawdzić aktualną wartość parametru i skąd pochodzi

W skrócie

Sprawdzenie, jaki jest aktualny parametr, brzmi banalnie, dopóki plik konfiguracyjny mówi jedno, a baza zachowuje się tak, jakby obowiązywało coś innego. Klucz w tym, że wartość obowiązująca w danej sesji to złożenie kilku poziomów ustawień, a nie prosty odczyt jednego pliku. Pokażemy Ci, jak jednym poleceniem odczytać wartość na żywo i jak sprawdzić jej źródło oraz to, czy zmiana zadziała od razu, czy dopiero po restarcie. Temat jest dla każdego, kto stroi bazę i chce mieć pewność, na czym stoi.

Jak to wygląda w praktyce

Otwierasz plik konfiguracyjny, widzisz w nim jakąś wartość, ale zachowanie bazy jej nie odpowiada. Albo zmieniłeś parametr, przeładowałeś serwer, a mimo to obowiązuje stara wartość. Bywa też, że w dwóch różnych sesjach ten sam parametr ma różne wartości i nie wiesz, skąd ta różnica. Zdarza się wreszcie, że zmiana w pliku po prostu nie skutkuje, choć składnia jest poprawna. Wspólny objaw to niepewność, jaka wartość naprawdę obowiązuje tu i teraz, i skąd się ona wzięła. Bez właściwych narzędzi wygląda to na kapryśność serwera.

Dlaczego tak się dzieje

PostgreSQL pozwala nadawać parametry na kilku poziomach, które nakładają się w ustalonej kolejności: plik serwera, ustawienia bazy, ustawienia roli i wreszcie sesja. Wartość, którą widzisz w połączeniu, to wynik tego nałożenia, więc wpis w pliku konfiguracyjnym może być przykryty przez ustawienie dla bazy, dla Twojej roli albo przez polecenie SET wykonane w sesji. Dlatego zaglądanie do samego pliku bywa mylące. Druga przyczyna to sposób wprowadzania zmian: część parametrów zaczyna obowiązywać dopiero po przeładowaniu konfiguracji, a część wyłącznie po pełnym restarcie serwera, bo zmiana dotyka struktur tworzonych przy starcie. Jeśli parametr wymaga restartu, a Ty zrobiłeś tylko reload, w pliku będzie już nowa wartość, ale serwer nadal działa na starej, wczytanej przy starcie. To najczęstsze źródło wrażenia, że zmiana nie działa.

Jak to rozwiązać krok po kroku

1. Odczytaj bieżącą wartość poleceniem SHOW parametr;. Pokazuje ono to, co faktycznie obowiązuje w Twojej sesji po nałożeniu wszystkich poziomów, a nie surowy wpis z pliku.
2. Aby zobaczyć naraz więcej danych o parametrze, odpytaj widok pg_settings: SELECT name, setting, source, context FROM pg_settings WHERE name = 'nazwa';.
3. Sprawdź kolumnę source. Powie Ci, czy wartość pochodzi z pliku konfiguracyjnego, z ustawienia bazy, z roli, czy z sesji. Dzięki temu wiesz, który poziom wygrał.
4. Zajrzyj do kolumny context. Wartość postmaster oznacza parametr wymagający restartu, sighup parametr wczytywany przez reload, a user parametr, który zmienisz w sesji bez żadnego przeładowania.
5. Jeśli plik ma już nową wartość, a SHOW pokazuje starą, ustal z kolumny context, czy parametr nie wymaga restartu. Jeżeli tak, wykonaj restart zamiast samego reload.
6. Gdy podejrzewasz przykrycie przez wyższy poziom, sprawdź ustawienia bazy i roli, na przykład przeglądając odpowiednie widoki systemowe albo polecając wyświetlenie ustawień przypisanych do bazy i do roli, i usuń zbędne nadpisanie, jeśli nie jest potrzebne.

Jak sprawdzić, że zadziałało

Najprostszy sprawdzian to ponowne wykonanie SHOW parametr; po zmianie i porównanie wyniku z tym, co zamierzałeś ustawić. Jeśli wartość się zgadza, zmiana obowiązuje w Twojej sesji. Dla pewności co do źródła zajrzyj jeszcze raz do pg_settings i sprawdź, czy kolumna source wskazuje ten poziom, na którym wprowadzałeś zmianę. Gdy parametr wymagał restartu, potwierdzeniem jest to, że po restarcie SHOW zwraca już nową wartość, a nie starą wczytaną przy poprzednim starcie. Warto też sprawdzić parametr w świeżo otwartym połączeniu, bo część ustawień działa dopiero od następnej sesji, a nie w bieżącej.

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5