Postgres pozwala zdefiniować progi wybranych liczników, po przekroczeniu których, aktywność użytkownika może być usunięta z serwera. Kilka z nich to:

• deadlock_timeout – czas po jakim zapytanie oczekujące na zwolnienie deadlock ma się „poddać”. Domyślna wartość to 1000 ms. Użytkownik może przedefiniować ten parametr
• statement_timeout – czas po jakim długo wykonujące się polecenie ma się przerwać. Można je ustawić globalnie lub dla wybranej funkcji. Domyślna wartość zero oznacza, że takiego limitu nie ma
• lock_timeout – czas po jakim długo trwające oczekiwanie na lock ma się przerwać. Ponieważ update statements muszą w pierwszej kolejności uzyskać lock na modyfikowanych rekordach, to lock_timeout powienien być mniejszy niż statement_timeout. Domyślnie ta wartość wynosi zero, co znaczy, że czekanie odbywa się bez limitu. Parametr ustawia się na sesję lub dla funkcji.
• idle_in_transaction_session_timeout – maksymalny czas, przez jaki może trwać transakcja nie podejmując żadnych nowych czynności. Jeśli ten czas zostanie przekroczony, to transakcja zostanie wycofana. Domyślna wartość zer określa, że nie ma żadnego limitu.

Technicznie zmiana parametru jest wykonywana poleceniem

SET configuration_parameter TO values;

Jeśli więc jedna sesja wykonała polecenie:

START TRANSACTION;

DELETE FROM rental WHERE rental_id=2

a druga wykona:

START TRANSACTION;
 
 SET lock_timeout TO 5000;
 
 UPDATE rental SET last_update = NOW() WHERE rental_id = 2

to po ok. 5 sekundach otrzymasz błąd w sesji drugiej:

ERROR: canceling statement due to lock timeout
CONTEXT: while locking tuple (0,1) in relation „rental”
SQL state: 55P03

Aby przywrócić oryginalną wartość parametru wystarczy wykonać:

SET lock_timeout TO values;

Jednym z zadań administratora jest obserwacja aktywności użytkowników i w skrajnych przypadkach przerwanie niepoprawnych lub zbyt intensywnych zapytań.

Sprawdzenie aktywności można wykonać poleceniem

SELECT * FROM pg_stat_activity;

W odpowiedzi zostanie zwrócony data set zawierający informacje o tym kto i co w danej chwili robi na serwerze:

Czytaj dalej »

Postgres można skonfigurować do przyjmowania połączeń tylko z określonych adresów IP. Służy do tego konfiguracja zapisana w pliku pg_hpa.conf.  To nie jest tak, że jeśli adres IP zostanie wprowadzony do tego pliku, to połączenie będzie po prostu nawiązywane (poza metodą „trust”). Konieczność jakiegoś uwierzytelnienia będzie zawsze obowiązywać. Plik ten należy traktować raczej jako dodatkowy front obrony. Jeśli są jakieś sieci lub adresy z których można się łączyć, to muszą tu być dodane, a jeśli chcesz żeby połączenie się nie odbywało, to albo dodaj taki adres z wpisem „reject”, albo po prostu nie dodawaj go do pliku. Modyfikacja pliku wymaga restartu serwera.

Plik jest czytany od góry do dołu i jego analiza kończy sie w momencie napotkania pierwszego pasującego wpisu. Np. konfiguracja w tej postaci:

# TYPE DATABASE USER ADDRESS METHOD

# following 2 lines were added to provoke connection failure on the local host
host all all 127.0.0.1/32 reject
host all all ::1/128 reject
# "local" is for Unix domain socket connections only
local all all scram-sha-256
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
# IPv6 local connections:
host all all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all scram-sha-256
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256

spowoduje zablokowanie połączeń z adresu 127.0.0.1 lub z odpowiednika ipv6 ::1.  Czytaj dalej »

PostgreSQL ma mnóstwo parametrów określających jego pracę, ale kilka jest na prawdę kluczowych:

• listen_addresses – adres na którym nasłuchuje serwer i pozwala się łączyć. Można go ustawić na konkretny adres IP, albo zmienić na *, co oznacza każdy interfejs
• port – określa port, na którym serwer nasłuchuje. Domyślny port to 5432 – chyba programista wybrał z klawiatury kolejne liczby….
• max_connections – ile maksymalnie może być nawiązanych połączeń. Jeśli wartość jest przekroczona, to połączenie koOperationalError: FATAL: sorry, too many clients already
• log_destination – określa format generowanych danych i sposób ich generowania. Domyślna opcja stderr określa, że informacje są wysyłane na standardowe wyjście, a pozmianie na csvlog, generowane dane będą w postaci nadającej się do dalszej analizy. Parametr może wymagać włączenia opcji logging_collection
• shared_buffers – współdzielona między sesjami pamięć cache, w której są przechowywane strony odczytane z dysku. Zazwyczaj wartość powinna być duża – zależnie od systemu np 25% wielkości pamięci RAM
• effective_cache_size – planowana ilość pamięci przewidziana do wykorzystania przez serwer. Wartość wpływa na to, jak serwer zdecyduje się wykonywać zapytania, np. niska ilość pamięci sprawia, że postgres będzie tak planował wykonywanie zapytań, aby w jak najmniejszym stopniu korzystać z pamięci, co zazwyczaj spowoduje wolną pracę serwera
• work_mem – maksymalna ilość pamięci przewidziana do wykonania pojedynczej czynności takiej jak sortowanie, join lub scan. Z jednej strony wysoka wartość tego parametru pozwala na szybkie wykonanie zadanej czynności, z drugiej ta wartość musi być pomnożona przez liczbę jednocześnie pracujących użytkowników. Zbyt wysoka wartość spowoduje więc szybką konsumpcję dostęnych zasobów
• maintenance_work_mem – opcja podobna do work_mem, ale dotyczy czynności administracyjnych i związanych z housekeepingiem. Nie powinna przekraczać 1GB
• max_parallel_workers_per_gather, max_parallel_workers – pozwalają zdefiniować liczbę wątków, które mogą być jednocześnie wykorzystane do wykonania jednego zapytania. Wartość nie może przekraczać max_parallel_workers

Serwer PostgreSQL jest konfigurowany za pomocą plików konfiguracyjnych. Te pliki można konfigurować bezpośrednio na poziomie systemu operacyjnego, ale coraz częściej takie podejście nie jest zalecane.

Np. zamiast modyfikować plik postgresql.conf można utworzyć nowy plik o nazwie postgresql.auto.conf i w nim umieścić przedefiniowane wartości parametrów. Jednak i to nie jest najlepsze rozwiązanie. Dodana w kolejnych wersjach posgresa komenda ALTER SYSTEM pozwala wprowadzać modyfikacje systemu z poziomu SQL:

ALTER SYSTEM SET max_connections = 130;

Dzięki temu ważne pliki konfiguracyjne pozostają w swojej oryginalnej postaci i co za tym idzie przechowują początkowe ustawienia. Modyfikacja plików wykonywana za pomocą komend pozwala unikać literówek, bądź wprowadzenia nonsensownych ustawień, które pozostają w konflikcie z innymi ustawieniami – polecenie ALTER SYSTEM chroni po prostu administratora przed niepoprawnymi modyfikacjami plików.

(Można też tworzyć własne pliki konfiguracyjne i dołączać je korzystając ze słowa include. Ta możliwość przyda się gdy modyfikujesz dużą liczbę parametrów).

Aktualne wartości parametrów można sprawdzić poleceniem

SELECT * FROM pg_settings

Tych ustawień jest całkiem sporo, dlatego aby zobaczyć te najważniejsze i najczęściej stosowane można uruchomić komendę: Czytaj dalej »

Czy to Windows, czy to Linux – postgres jest procesem, który w pewnych przypadkach trzeba zrestartować. W takim przypadku skorzystaj z polecenia restart. Tak wygląda to na Windows:

"C:\Program Files\PostgreSQL\13\bin\pg_ctl.exe" restart -D "C:/Program Files/PostgreSQL/13/data/"

a tak na Linuxie:

service postgresql-X.Y restart

Jeśli z jakiegoś powodu (np. źle zdefiniowanych parametrów uruchomieniowych) serwer nie startuje, to przyczyny należy szukać w  plikach logów, które znajdują się w podkatalogu log katalogu data:

C:\Program Files\PostgreSQL\13\data\log

Konfigurację postgres-a zapisuje sie w plikach konfiguracyjnych. W zależności od tego, jak została przeprowadzona instalacja, te pliki mogą się znajdować w różnych lokalizacjach. Jeśli trzeba ustalić dokładne ścieżki do tych plików, to uruchom następujące polecenie:

SELECT name, setting FROM pg_settings WHERE category = 'File Locations';

Czytaj dalej »