Zmiana parametru w postgresql.conf nie działa - reload czy restart

PostgreSQL

W skrócie

Problem: zmieniłeś parametr w postgresql.conf, a serwer dalej działa po staremu - zmiana nie zadziałała.
Dlaczego: część parametrów wymaga tylko przeładowania (reload), a część pełnego restartu. Zmieniasz jedno, gdy potrzebne jest drugie, albo edytujesz plik przesłonięty przez inny.
Rozwiązanie: sprawdzamy w widoku pg_settings, jaki kontekst ma parametr, wykonujemy właściwą operację i weryfikujemy wartość na żywo.

Wielu administratorów zmienia wpis w postgresql.conf, po czym dziwi się, że nic się nie stało. Sedno tkwi w tym, że PostgreSQL dzieli parametry na kategorie według sposobu ich zastosowania - jedne wystarczy przeładować, inne wymagają restartu całego serwera. Do tego dochodzi mechanizm nadpisywania ustawień na różnych poziomach. Ten problem dotyczy każdego, kto stroi wydajność albo zmienia zachowanie bazy. Pokazujemy, jak sprawdzić, czego dany parametr wymaga, i jak potwierdzić zmianę.

Jak to wygląda w praktyce

Edytujesz plik, przeładowujesz konfigurację, a wartość w bazie ani drgnie:

# w postgresql.conf zmieniamy:
shared_buffers = 512MB

$ sudo systemctl reload postgresql
$ psql -c "SHOW shared_buffers;"
 shared_buffers
----------------
 128MB

Parametr dalej ma starą wartość, mimo że w pliku jest już nowa. To nie błąd - shared_buffers należy do grupy parametrów, które można zmienić wyłącznie przy restarcie serwera. Reload takich ustawień po prostu nie rusza.

Dlaczego tak się dzieje

Każdy parametr w PostgreSQL ma tak zwany kontekst, widoczny w kolumnie context widoku pg_settings. Kontekst sighup oznacza, że parametr aktualizuje się przy przeładowaniu konfiguracji (reload wysyła procesowi serwera sygnał HUP). Kontekst postmaster oznacza parametr wczytywany tylko przy starcie procesu głównego - taki wymaga pełnego restartu, na przykład shared_buffers, listen_addresses, max_connections czy wal_level. Są też konteksty user i superuser, gdzie parametr można zmienić w ramach sesji poleceniem SET. Druga częsta przyczyna to nadpisywanie - wartość ustawiona przez ALTER SYSTEM ląduje w pliku postgresql.auto.conf, który jest wczytywany po postgresql.conf i przesłania Twój ręczny wpis.

Jak to rozwiązać krok po kroku

Sprawdź, jaki kontekst ma parametr: SELECT name, setting, context, pending_restart FROM pg_settings WHERE name = 'shared_buffers';.
Jeśli kontekst to sighup, wystarczy reload: sudo -u postgres psql -c "SELECT pg_reload_conf();" lub sudo systemctl reload postgresql.
Jeśli kontekst to postmaster, potrzebny jest pełny restart: sudo systemctl restart postgresql - dopiero wtedy nowa wartość wejdzie w życie.
Sprawdź, czy parametru nie przesłania postgresql.auto.conf (efekt wcześniejszego ALTER SYSTEM). Jeśli tak, ustaw wartość spójnie przez ALTER SYSTEM SET shared_buffers = '512MB'; albo wyczyść wpis przez ALTER SYSTEM RESET shared_buffers;.
Upewnij się, że edytujesz właściwy plik - ścieżkę pokaże SHOW config_file;. Łatwo pomylić plik przy kilku klastrach na jednej maszynie.
Kolumna pending_restart w pg_settings ustawiona na t to sygnał, że zmiana czeka na restart serwera - zaplanuj go w oknie serwisowym.

Jak sprawdzić, że zadziałało

Po właściwej operacji potwierdź nową wartość na żywo w serwerze - a przy okazji sprawdź, czy nic już nie czeka na restart:

SELECT name, setting, unit, context, pending_restart
FROM pg_settings
WHERE name = 'shared_buffers';

Jeśli setting odpowiada nowej wartości, a pending_restart jest f, zmiana jest aktywna. Możesz też odczytać ją prościej: SHOW shared_buffers;.

Poczytaj więcej
Lekcja z kursu PostgreSQL na ten temat
Cały bezpłatny kurs administracji PostgreSQL

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

Autorzy

Tekst: Redakcja JSystems

Najczęściej zadawane pytania

Skąd wiadomo, czy parametr wymaga reload, czy restartu?

Z kolumny context w widoku pg_settings. Kontekst sighup oznacza, że parametr da się zmienić przez reload, czyli pg_reload_conf() albo systemctl reload. Kontekst postmaster oznacza, że parametr wczytywany jest tylko przy starcie i wymaga pełnego restartu serwera. Wystarczy SELECT name, context FROM pg_settings WHERE name = 'nazwa', aby to sprawdzić.

Czym różni się pg_reload_conf() od restartu serwera?

pg_reload_conf() wysyła działającemu serwerowi sygnał przeładowania plików konfiguracyjnych, bez zrywania połączeń - działa dla parametrów o kontekście sighup oraz dla pg_hba.conf. Restart zatrzymuje i uruchamia proces serwera od nowa, zrywając sesje, i jest konieczny dla parametrów o kontekście postmaster, takich jak shared_buffers czy max_connections.

Do czego służy plik postgresql.auto.conf?

To plik, do którego PostgreSQL zapisuje ustawienia wykonane poleceniem ALTER SYSTEM. Jest wczytywany po postgresql.conf, więc przesłania wartości wpisane tam ręcznie. Jeśli zmiana w postgresql.conf nie działa, sprawdź, czy tego parametru nie nadpisuje wpis w postgresql.auto.conf - można go zmienić przez ALTER SYSTEM SET albo usunąć przez ALTER SYSTEM RESET.

Co oznacza kolumna pending_restart w pg_settings?

Wartość true w kolumnie pending_restart mówi, że zmieniłeś parametr wymagający restartu i nowa wartość znajduje się już w konfiguracji, ale zacznie obowiązywać dopiero po ponownym uruchomieniu serwera. To wygodny sposób, by sprawdzić, czy jakieś zmiany czekają na okno serwisowe, zanim faktycznie zrestartujesz klaster produkcyjny.