Przewodnik rozwiązywania problemów z PostgreSQL w ServBay

PostgreSQL to zaawansowany i bogaty w funkcje system relacyjnych baz danych open source, szeroko wykorzystywany w aplikacjach webowych i do przechowywania danych. Jako kluczowy pakiet w lokalnym środowisku developerskim ServBay, PostgreSQL zwykle działa stabilnie. Jednak czasami możesz natrafić na trudności, takie jak brak możliwości uruchomienia pakietu, problemy z połączeniem, spadek wydajności lub niespodziewane błędy dostępu do danych.

Ten artykuł jest szczegółowym przewodnikiem rozwiązywania problemów z PostgreSQL dla programistów korzystających z ServBay. Przedstawiamy najczęstsze awarie pakietu PostgreSQL w środowisku ServBay, kroki diagnostyczne oraz praktyczne rozwiązania. ServBay obsługuje systemy macOS i Windows, integrując różne wersje pakietu PostgreSQL, dlatego przy niektórych operacjach naprawczych lub diagnostycznych może być konieczne wskazanie konkretnej wersji, pliku konfiguracyjnego lub ścieżki do katalogu danych.

Omówienie

Ten poradnik skupia się na technicznych problemach, które mogą pojawić się podczas zarządzania i użytkowania pakietu PostgreSQL w środowisku ServBay. Zaczynamy od najczęstszych kwestii związanych z uruchamianiem i połączeniem, następnie omawiamy zagadnienia wydajności, awarie oraz backup i przywracanie danych. Postępując zgodnie z tymi wskazówkami, będziesz w stanie systematycznie diagnozować i rozwiązywać większość problemów z PostgreSQL.

Wymagania wstępne

Przed rozpoczęciem rozwiązywania problemów upewnij się, że:

1. ServBay jest poprawnie zainstalowany i uruchomiony na Twoim komputerze.
2. Zainstalowałeś przez ServBay właściwą wersję pakietu PostgreSQL, którą chcesz diagnozować.
3. Posiadasz podstawową znajomość obsługi terminala/wiersza poleceń.
4. Znasz ścieżki do plików konfiguracyjnych oraz katalogów danych PostgreSQL:
   • macOS: /Applications/ServBay/db/postgresql/<wersja>
   • Windows: C:\ServBay\db\postgresql\<wersja>
5. Znasz nazwę baz danych, nazwę użytkownika oraz hasło, z których korzystasz.

Najczęstsze problemy i sposoby rozwiązania

1. Pakiet PostgreSQL nie uruchamia się

Jeśli próbujesz uruchomić pakiet PostgreSQL przez ServBay, lecz jego status wyświetla się jako zatrzymany lub uruchomienie zakończyło się niepowodzeniem, możliwe przyczyny to:

Możliwe przyczyny

• Błędy składni lub konflikty w plikach konfiguracyjnych.
• Port używany przez PostgreSQL (domyślnie 5432) jest zajęty przez inny proces.
• Brak odpowiednich uprawnień do odczytu/zapisu na katalogach danych lub plikach konfiguracyjnych pakietu PostgreSQL bądź ServBay.
• Uszkodzony katalog danych PostgreSQL.
• Problemy w zarządzaniu pakietami po stronie ServBay.

Sposoby rozwiązania

1. Sprawdź status i logi w GUI ServBay: Najpierw otwórz interfejs ServBay i sprawdź stan pakietu PostgreSQL. Jeżeli występuje błąd, spróbuj ręcznie uruchomić pakiet przez GUI. Następnie sprawdź główny log ServBay lub log dedykowany dla pakietu PostgreSQL.

Lokalizacja plików logów:

• macOS: /Applications/ServBay/logs/postgresql/<wersja>/postgresql-<wersja>.log
• Windows: C:\ServBay\logs\postgresql\<wersja>\postgresql-<wersja>.log

2. Sprawdź pliki konfiguracyjne: Głównym plikiem konfiguracyjnym PostgreSQL jest postgresql.conf. Upewnij się, że nie zawiera błędów składni, literówek lub niewłaściwych ustawień.

Przykładowe ścieżki plików konfiguracyjnych (dla PostgreSQL 13):

• macOS: /Applications/ServBay/db/postgresql/13/postgresql.conf
• Windows: C:\ServBay\db\postgresql\13\postgresql.conf

Innym ważnym plikiem jest pg_hba.conf, który reguluje autoryzację użytkowników. Błędna konfiguracja może skutkować problemami z połączeniem lub nawet uruchomieniem serwera. Zazwyczaj plik ten znajduje się w tym samym katalogu co postgresql.conf.

PostgreSQL nie posiada dedykowanego narzędzia CLI do sprawdzania poprawności całej konfiguracji. Błędy pojawiają się jednak w logach podczas ładowania konfiguracji. Możesz także, jeżeli serwer innej wersji działa, podłączyć się przez `psql` do niej i sprawdzić niektóre ustawienia. Najlepiej jednak sprawdzić wpisy błędów w logach.

W przypadku `pg_hba.conf` możesz z poziomu SQL sprawdzić załadowane reguły:
```sql
-- Wymaga połączenia z bazą danych
SELECT * FROM pg_hba_file_rules();
```
Błędy podczas ładowania konfiguracji sprawdzisz przez:
```sql
-- Wymaga połączenia z bazą danych
SELECT sourcefile, name, sourceline, error FROM pg_file_settings WHERE error IS NOT null;
```
**Uwaga:** Powyższe polecenia SQL działają tylko, gdy PostgreSQL jest już uruchomiony. Przy problemach z uruchomieniem kluczowe jest sprawdzenie logów.

3. Sprawdź zajętość portu: Domyślnie PostgreSQL nasłuchuje na porcie 5432. Jeśli port jest zajęty, serwer nie wystartuje.

Sprawdzanie portu:

macOS:

lsof -i :5432

Windows:

netstat -an | findstr :5432
# lub PowerShell
Get-NetTCPConnection -LocalPort 5432

Jeśli pojawi się wynik, oznacza to, że port jest używany przez inny proces. Na podstawie PID (identyfikatora procesu) możesz zidentyfikować aplikację i zdecydować, czy ją zatrzymać lub zmienić domyślny port PostgreSQL (poprzez modyfikację parametru port w postgresql.conf, a następnie ponownie uruchomić pakiet PostgreSQL przez ServBay GUI lub servbayctl).

4. Sprawdź uprawnienia do plików i katalogów: ServBay musi mieć pełne uprawnienia do odczytu i zapisu na katalogach instalacyjnych oraz plikach konfiguracyjnych PostgreSQL. Zwykle ServBay uruchamiany jest jako bieżący użytkownik, więc musisz posiadać prawa właściciela lub grupy do katalogu /Applications/ServBay/.

Sprawdzanie uprawnień:

macOS:

ls -ld /Applications/ServBay/db/postgresql/13 # katalog danych
ls -l /Applications/ServBay/db/postgresql/13/postgresql.conf # plik konfiguracyjny
ls -l /Applications/ServBay/db/postgresql/13/pg_hba.conf # plik autoryzacyjny

Windows: W systemie Windows użyj Eksploratora plików do sprawdzenia właściwości plików i katalogów, i potwierdź, że konto usługi ServBay posiada właściwe uprawnienia. Jeśli coś jest nie tak, naprawę wykonaj ostrożnie, najlepiej reinstalując pakiet przez ServBay.

5. Sprawdź uszkodzenie katalogu danych: Katalog danych PostgreSQL zawiera wszystkie pliki bazowe. Jego uszkodzenie (np. przez nagły restart systemu lub błędy dysku) może uniemożliwić uruchomienie bazy. Oznaki uszkodzenia pojawią się w logach. Naprawa takiego katalogu bywa trudna i czasem wymaga użycia specjalistycznych narzędzi (np. pg_resetwal, który jednak niesie ryzyko utraty danych). Zawsze wykonaj backup katalogu przed próbą naprawy – nawet jeśli jest uszkodzony.

6. Spróbuj ponownie uruchomić przez polecenie ServBay: Po zweryfikowaniu powyższych przyczyn użyj polecenia ServBay do restartu konkretnej wersji PostgreSQL:

   servbayctl restart postgresql 13

   Alternatywnie użyj przycisku w interfejsie ServBay GUI.

2. Problem z połączeniem z PostgreSQL

Mimo że pakiet PostgreSQL wydaje się działać, nie udaje się połączyć przez narzędzia klienckie (psql, pgAdmin czy aplikacje własne).

Możliwe przyczyny

• Serwer PostgreSQL tak naprawdę nie jest aktywny lub działa niepoprawnie.
• Konfiguracja pg_hba.conf nie pozwala na Twoje połączenie.
• Zapora blokuje połączenie.
• Parametry połączenia (adres hosta, port, nazwa bazy, użytkownik, hasło) są błędne.
• Użytkownik nie ma uprawnień do bazy.

Sposoby rozwiązania

1. Sprawdź status pakietu przez GUI lub servbayctl: Upewnij się, że w GUI ServBay pakiet PostgreSQL jest "aktywny". Jeśli nie, wróć do poprzedniego rozdziału. Możesz także sprawdzić status przez CLI:

   servbayctl status postgresql 13

   W rezultacie powinno pojawić się potwierdzenie uruchomionego pakietu.

2. Sprawdź konfigurację pg_hba.conf: Ten plik steruje, które hosty, użytkownicy i bazy oraz jakie metody uwierzytelnienia mogą się łączyć z PostgreSQL – jest to najczęstsza przyczyna problemów z połączeniem. Dla lokalnego środowiska powinieneś zezwolić na połączenia z localhost i 127.0.0.1.

Ścieżki pliku pg_hba.conf:

• macOS: /Applications/ServBay/db/postgresql/13/pg_hba.conf

• Windows: C:\ServBay\db\postgresql\13\pg_hba.conf

  Przykład reguł zezwalających demo użytkownikowi ServBay na połączenie lokalne z użyciem hasła md5:

  # TYPE  DATABASE        USER            ADDRESS                 METHOD
  host    all             servbay-demo    127.0.0.1/32            md5
  host    all             servbay-demo    ::1/128                 md5

  Po edycji pliku przeładuj konfigurację (nie musisz restartować całego pakietu):

  servbayctl reload postgresql 13

  lub przez GUI ServBay.

3. Sprawdź ustawienia zapory sieciowej (firewall):macOS:

# Dodaj aplikację do listy wyjątków
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/postgres
# Upewnij się, że nie jest blokowana
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/postgres

Windows: Sprawdź ustawienia Windows Defender albo innej zapory. Możesz dodać regułę pozwalającą na ruch na wybranym porcie:

netsh advfirewall firewall add rule name="ServBay PostgreSQL" dir=in action=allow program="C:\ServBay\bin\postgresql\<wersja>\bin\postgres.exe"

4. Zweryfikuj parametry połączenia i uprawnienia użytkownika: Upewnij się, że w stringu połączeniowym lub narzędziu klienckim podałeś właściwą nazwę hosta (localhost lub 127.0.0.1), port (domyślnie 5432), nazwę bazy, użytkownika i hasło. Test najprostszy z użyciem psql:

   psql -U twoja_nazwa_uzytkownika -d twoja_baza -h localhost -p 5432

   Podstaw twoja_nazwa_uzytkownika i twoja_baza odpowiednio. Jeżeli połączenie się udaje, otrzymasz prompt psql. Jeśli nie, w komunikacie błędu odczytasz przyczynę (brak uprawnień, złe hasło, nieistniejąca baza itp.).

   Jeśli po połączeniu nie masz dostępu do określonych baz lub tabel, sprawdź role użytkowników przez komendę \du w psql:

   -- Wewnątrz konsoli psql
   \du

   Jeżeli trzeba, zaloguj się jako użytkownik z uprawnieniami administracyjnymi (np. domyślny postgres) i nadaj prawa przez GRANT.

3. Problemy z wydajnością

Pakiet PostgreSQL uruchamia się i umożliwia połączenia, lecz zapytania są wolne – występują kłopoty z wydajnością.

Możliwe przyczyny

• Nieoptymalne lub źle napisane zapytania SQL.
• Niewłaściwie zaprojektowany schemat bazy danych.
• Niewłaściwe ustawienia parametrów pamięci i cache.
• Brak wymaganych indeksów.
• Niedostateczne zasoby sprzętowe (CPU, RAM, dysk).
• Przestarzałe statystyki bazy.

Sposoby rozwiązania

1. Analizuj i optymalizuj zapytania: Skorzystaj z EXPLAIN lub EXPLAIN ANALYZE, aby przeanalizować plan wykonania wolnych poleceń SQL. Dowiesz się, czy korzystają z indeksów, w jakiej kolejności są łączone tabele i gdzie pojawia się problem z wydajnością.

   -- W konsoli psql lub innym kliencie SQL
   EXPLAIN ANALYZE SELECT * FROM your_table_name WHERE column_name = 'value';

   Na podstawie wyników możesz modyfikować zapytania, zakładać indeksy lub dostosowywać strukturę bazy.

2. Dostosuj parametry wydajnościowe w postgresql.conf: Plik konfiguracyjny zawiera wiele ustawień wpływających na wydajność, zwłaszcza tych związanych z pamięcią oraz operacjami dyskowymi. Najważniejsze:

   • shared_buffers: określa ilość RAM-u przeznaczonego na cache danych w PostgreSQL. Zwiększenie wartości może poprawić wydajność, ale nie powinno przekraczać rozsądnego udziału w pamięci systemowej (najlepiej do ok. 25% RAM).
   • work_mem: reguluje ilość pamięci dla operacji sortowania lub hash. Podniesienie wartości pomaga przy dużych zapytaniach, zmniejsza ryzyko tworzenia plików tymczasowych na dysku.

   Ustawienia dopasuj do swoich zasobów i typowych zadań. Po zmianach przeładuj lub uruchom ponownie pakiet PostgreSQL.

   # Przykładowe ustawienia w zależności od RAM-u
   shared_buffers = 1GB # np. gdy w systemie dostępne jest 4GB
   work_mem = 64MB # wg potrzeb

3. Tworzenie odpowiednich indeksów: Zakładaj indeksy na kolumnach często wykorzystywanych w klauzulach WHERE, JOIN lub ORDER BY. Przed dodaniem indeksu użyj EXPLAIN, by ocenić, czy rzeczywiście poprawi to wydajność.

   -- Przykład: indeks na kolumnę column_name w tabeli your_table_name
   CREATE INDEX idx_column_name ON your_table_name(column_name);

   Uwaga: zbyt wiele indeksów obciąża operacje zapisów i zwiększa zajętość dysku. Twórz wyłącznie niezbędne indeksy.

4. Aktualizuj statystyki bazy danych: Optymalizator zapytań PostgreSQL wykorzystuje statystyki dotyczące zawartości tabel i indeksów. Po dużych zmianach w danych mogą się zdezaktualizować, prowadząc do nieefektywnych planów wykonania. Regularnie uruchamiaj ANALYZE:

   -- Cała baza
   ANALYZE;
   -- Jedna tabela
   ANALYZE your_table_name;

   ServBay zwykle konfiguruje automatyczną analiza i czyszczenie (autovacuum), lecz manualna analiza przy rozwiązywaniu problemów jest bardzo pomocna.

5. Sprawdzanie zasobów sprzętowych: Choć ServBay to środowisko lokalne, duże bazy danych lub wymagające zapytania mogą obciążać Twój komputer (CPU, RAM, dysk – szczególnie jeśli używasz HDD zamiast SSD). Skorzystaj z systemowych narzędzi do monitorowania (Activity Monitor na macOS itp.), aby sprawdzić, czy istnieje ograniczenie sprzętowe.

4. Awaria bazy danych

Pakiet PostgreSQL nagle się zatrzymuje lub nie odpowiada – mamy do czynienia z awarią.

Możliwe przyczyny

• Awaria sprzętowa (błędy RAM, dysku).
• Problemy z systemem operacyjnym lub limitami zasobów.
• Błędy w samym PostgreSQL (rzadkie, zwykle związane z konkretną wersją lub nietypową sytuacją).
• Uszkodzenie katalogu danych.
• Błędna konfiguracja prowadząca do wyczerpania zasobów (np. zbyt wiele połączeń).

Sposoby rozwiązania

1. Sprawdź logi PostgreSQL: Podczas awarii PostgreSQL zapisuje szczegółowe informacje o błędach. To pierwszy krok w diagnozie.

Lokalizacja logów:

• macOS: /Applications/ServBay/logs/postgresql/<wersja>/postgresql-<wersja>.log
• Windows: C:\ServBay\logs\postgresql\<wersja>\postgresql-<wersja>.log

Wyszukaj wpisy o poziomie FATAL lub ERROR, szczególnie te z momentu wystąpienia awarii. Log z reguły zawiera konkretny powód – błąd pamięci, dysku, naruszenie integralności danych itd.

2. Sprawdź logi systemowe: Poza logami PostgreSQL także dziennik systemowy macOS (Konsola) może zawierać informacje o awariach sprzętu lub problemach z systemem, które przyczyniły się do awarii bazy.

3. Test sprzętu: Użyj wbudowanych narzędzi diagnostycznych macOS lub programów firm trzecich do testowania RAM i dysku. Uszkodzenia dysku są częstą przyczyną awarii i utraty danych.

4. Naprawa lub rekonstrukcja katalogu danych (ostrożnie!): Jeśli logi wskazują na uszkodzenie katalogu danych, skorzystaj z narzędzi niskopoziomowych, takich jak pg_resetwal, które resetują logi transakcyjne. To ryzykowne, grozi utratą danych, dlatego używaj tych narzędzi jedynie jako ostatniej szansy.

   Bezpieczniejsze i zalecane podejście: a. Zrób kopię katalogu danych: Nawet uszkodzonego. b. Zainicjuj nowy katalog: Zatrzymaj pakiet PostgreSQL, przenieś stary katalog i użyj polecenia initdb, żeby utworzyć nowy (ServBay zwykle robi to przy reinstalacji pakietu). c. Przywróć dane z backupu: Skorzystaj z pg_restore lub psql na bazie backupu.

5. Przywróć dane z backupu: Jeśli katalog danych jest uszkodzony i nie daje się naprawić lub musisz przywrócić starszy stan, najlepiej użyj backupów (automatycznych lub manualnych z ServBay).

   Lokalizacja backupów:

   • macOS: /Applications/ServBay/backup/postgresql/<wersja>/
   • Windows: C:\ServBay\backup\postgresql\<wersja>\

5. Problemy z backupem i przywracaniem

ServBay obsługuje backup manualny i automatyczny PostgreSQL. Problemy przy backupie lub odtwarzaniu możesz rozwiązać według poniższych kroków.

Możliwe przyczyny

• Uszkodzony plik backupu lub niepełny backup.
• Niewłaściwe polecenia/parametry przy odtwarzaniu.
• Brak docelowej bazy lub uprawnień użytkownika.
• Brak miejsca na dysku.
• Przerwanie backupu/odtwarzania.

Sposoby rozwiązania

1. Sprawdź integralność plików backupu: Upewnij się, że plik backupu (pg_dump, automatyczny lub manualny backup ServBay) ma prawidłowy rozmiar i nie uległ uszkodzeniu podczas przesyłania lub zapisu. Backupy tekstowe możesz obejrzeć w edytorze – pliki w formatach custom lub directory sprawdzisz przez pg_restore.

Lokalizacja backupów:

• macOS: /Applications/ServBay/backup/postgresql/13/your_backup_file.dump
• Windows: C:\ServBay\backup\postgresql\13\your_backup_file.dump

Sprawdź rozmiar pliku:

• macOS: ls -lh /Applications/ServBay/backup/postgresql/13/your_backup_file.dump
• Windows: dir C:\ServBay\backup\postgresql\13\your_backup_file.dump

2. Poprawne używanie poleceń przywracania pg_restore lub psql: Wybór polecenia zależy od formatu backupu.

   • Backup tekstowy (pg_dump -Fp lub bez podania formatu): przywracasz przez psql:

     psql -U twoja_nazwa_uzytkownika -d twoja_baza -h localhost -p 5432 -f /ścieżka/do/your_backup_file.sql

     Docelowa baza twoja_baza musi już istnieć.
   • Backup w formacie custom (-Fc) lub directory (-Fd): przywracasz przez pg_restore:

     pg_restore -U twoja_nazwa_uzytkownika -d twoja_baza -h localhost -p 5432 /ścieżka/do/your_backup_file.dump

     Również tu baza musi istnieć. pg_restore daje więcej opcji, np. odtwarzanie tylko wybranych obiektów.

   Upewnij się, że użytkownik ma odpowiednie prawa do docelowej bazy (najlepiej właściciel lub superuser, np. domyślny postgres).

3. Utworzenie docelowej bazy: Przed przywracaniem backupu docelowa baza musi istnieć:

   createdb -U twoja_nazwa_uzytkownika -h localhost -p 5432 twoja_baza

   Możesz ją utworzyć także przez GUI ServBay lub inny program do zarządzania bazą.

4. Sprawdź miejsce na dysku: Przy przywracaniu dużych backupów upewnij się, że masz wystarczająco wolnego miejsca.

5. Weryfikacja konfiguracji backupów i logów ServBay: Jeśli korzystasz z automatycznych backupów ServBay i napotkasz problemy, sprawdź ustawienia backupu oraz odpowiednie logi ServBay, by znaleźć przyczynę błędu (np. niewystarczająca ilość miejsca lub błędna konfiguracja harmonogramu backupów).

Najczęściej zadawane pytania (FAQ)

• Jak znaleźć katalog danych PostgreSQL w ServBay? Odpowiedź: Katalog danych PostgreSQL znajdziesz tutaj:

  • macOS: /Applications/ServBay/db/postgresql/<wersja>/data
  • Windows: C:\ServBay\db\postgresql\<wersja>\data

  Lokalizacja plików konfiguracyjnych:

  • macOS: /Applications/ServBay/db/postgresql/<wersja>/
  • Windows: C:\ServBay\db\postgresql\<wersja>\

• Jak zresetować hasło użytkownika postgres w pakiecie PostgreSQL w ServBay? Odpowiedź: Jeśli zapomniałeś hasła superużytkownika postgres lub chcesz zresetować hasło dowolnego użytkownika, zrób tak (zakładając, że masz uprawnienia do połączenia trust lub superusera):

  1. Zatrzymaj pakiet PostgreSQL w ServBay.

  2. Edytuj plik pg_hba.conf, ustawiając tymczasowo metodę połączenia lokalnego na trust.

     • macOS: /Applications/ServBay/db/postgresql/13/pg_hba.conf
     • Windows: C:\ServBay\db\postgresql\13\pg_hba.conf

     Znajdź linie:

     # TYPE  DATABASE        USER            ADDRESS                 METHOD
     local   all             all                                     peer  # lub md5
     host    all             all             127.0.0.1/32            md5   # lub scram-sha-256 itd.

     Zmień na (tylko lokalnie!):

     # TYPE  DATABASE        USER            ADDRESS                 METHOD
     local   all             all                                     trust
     host    all             all             127.0.0.1/32            trust
     host    all             all             ::1/128                 trust

  3. Uruchom ponownie pakiet PostgreSQL przez ServBay.

  4. Połącz się z bazą bez podania hasła jako postgres:

     psql -U postgres -h localhost -p 5432

  5. Na konsoli psql użyj polecenia SQL do zmiany hasła:

     ALTER USER postgres PASSWORD 'nowe_bezpieczne_haslo';

     Zamień 'nowe_bezpieczne_haslo' na wybrane hasło. Dla innych użytkowników zmień postgres na właściwą nazwę.

  6. Zakończ psql przez \q.

  7. WAŻNE: Zatrzymaj PostgreSQL, przywróć w pliku pg_hba.conf poprzednią metodę uwierzytelniania (np. md5 lub scram-sha-256) i uruchom ponownie pakiet PostgreSQL przez ServBay.

• Czy ServBay obsługuje wysoką dostępność lub replikację PostgreSQL? Odpowiedź: ServBay jest projektowany jako środowisko lokalne dla programistów, z wygodnym zarządzaniem pakietami i integracją. Nie oferuje gotowej, produkcyjnej obsługi replikacji ani wysokiej dostępności przez GUI. Możesz samodzielnie skonfigurować replikację strumieniową PostgreSQL, ale wymaga to dogłębnej wiedzy i pracy w terminalu.

• Jak zaktualizować wersję pakietu PostgreSQL w ServBay? Odpowiedź: ServBay umożliwia instalację i zarządzanie wieloma wersjami pakietów PostgreSQL. Aktualizacja polega zwykle na zainstalowaniu nowej, wyższej wersji i migracji danych ze starej wersji na nową za pomocą narzędzia pg_upgrade. Proces ten obejmuje zatrzymanie obu wersji, uruchomienie pg_upgrade i uruchomienie nowej wersji. Szczegóły znajdziesz w oficjalnej dokumentacji PostgreSQL – w ServBay katalogi danych dla różnych wersji są oddzielone, co ułatwia migrację.