# Frequently Asked Questions (FAQ) o PostgreSQL

Ostatnia aktualizacja: Sobota Luty 7 22:16:21 EST 2004

Ostatnia aktualizacja tłumaczenia: Piątek Marzec 5 19:31:12 EST 2004

Obecny maintainer: Bruce Momjian (pgman@candle.pha.pa.us)

Tłumaczenie: Marcin Mazurek (m.mazurek@netsync.pl)

Najbardziej aktualną wersję tego dokumentu można znaleźć pod adresem: http://www.PostgreSQL.org/docs/faqs/FAQ.html.

Odpowiedzi na pytania dotyczące konkretnych systemów operacyjnych można znaleźć pod adresem: http://www.PostgreSQL.org/docs/index.html.

## Pytania ogólne

1.1) Co to jest PostgreSQL? Jak to wymawiać?
1.2) Jaką licencją chroniony jest PostgreSQL?
1.3) Na jakich systemach Unixowych działa PostreSQL?
1.4) Na jakich nie-Unixowych systemach działa PostgreSQL?
1.5) Skąd mogę ściągnąć PostgreSQL?
1.6) Gdzie można szukać wsparcia technicznego?
1.7) Jaka jest ostatnia dostępna wersja?
1.8) Jaka dokumentacja jest dostępna?
1.9) Gdzie mogę znaleźć informację o znanych błędach czy brakujących rozwiązanich?
1.10) Jak mogę się nauczyć SQL?
1.11) Czy PostgreSQL ma rozwiązany problem Y2K?
1.12) Jak mogę się przyłączyć do grupy osób bezpośrednio pracujących nad rozwojem PostgreSQL?
1.13) Jak mogę zgłaszać błędy?
1.14) Jak można porównać PostgreSQL w stosunku do innych DBMS?
1.15) W jaki sposób mogę wesprzeć finansowo PostgreSQL?

## Pytania użytkowników

2.1) Czy są jakieś driwery ODBC dla PostgreSQL?
2.2) Jakie istnieją narzędzia pozwalające na dostęp do PostgreSQL przez www?
2.3) Czy istnieje jakieś GUI dla PostgreSQL?
2.4) Za pomocą jakich języków programowania można się komunikować z PostgreSQL?

## Pytania dotyczące administracji

3.1) Jak mogę zainstalować PostgreSQL w innej lokalizacji niż /usr/local/pgsql?
3.2) Podczas startu postmaster'a, otrzymuję komunikat: Bad System Call lub "core dumped". Dlaczego?
3.3) Podczas startu postmaster'a, otrzymuję komunikat o błędzie: IpcMemoryCreate. Dlaczego?
3.4) Podczas startu postmaster'a, otrzymuję komunikat o błędzie: IpcSemaphoreCreate. Dlaczego?
3.5) W jaki sposób mogę kontrolować połączenia z innych hostów?
3.6) Jak powinienem skonfigurować system baz danych aby uzyskać lepszą wydajność?
3.7) Jakie są możliwości wyszukiwania błędów?
3.8) Skąd się bierze komunikat: "Sorry, too many clients" podczas próby połączenia się z bazą danych?
3.9) Jakie pliki znajdują się w pg_temp?
3.10) Dlaczego konieczne jest przy upgradzie PostgreSQL korzystanie ze skryptów dump i restore?

## Pytania dotyczące użytkowania

4.1) Jaka jest różnica pomiędzy kursorami binarnymi (binary cursors) i zwykłymi kursorami (normal cursors)?
4.2) Jak mogę pobrać za pomocą SELECT jedynie kilka pierwszych wyników zapytania?
4.3) Jak mogę uzyskać listę wszystkich tabel czy innych rzeczy pod psql?
4.4) Jak usunąć kolumnę z tabeli lub zmienić jej typ?
4.5) Jaki jest maksymalny rozmiar dla rzędu, tabeli i bazy danych?
4.6) Jak dużo miejsca w bazie danych jest potrzebne aby przechować dane ze zwyczajnego pliku tekstowego?
4.7) Jak mogę sprawdzić jakie tabele, klucze, bazy danych i użytkownicy są utworzeni?
4.8) Moje zapytania są wolne lub nie używają kluczy. Dlaczego?
4.9) Jak mogę sprawdzić w jakis sposób "query optimizer" wykonuje moje zapytanie?
4.10) Co to jest "R-tree index"?
4.11) Co to jest "Genetic Query Optimizer"?
4.12) Jak mogę używać wyrażeń regularnych w zapytaniach i zapytań case-insensitive w wyrażeniach regularnych? Jak korzystać z indeksów dla zapytań case-insensitive?
4.13) Jak sprawdzić w zapytaniu czy pole ma wartość NULL?
4.14) Jaka jest różnica pomiędzy różnymi typami tekstowymi (character types)?
4.15.1) Jak mogę utworzyć pole typu int, które samo zwiększa swoją wartość?
4.15.2) Jak pobrać wartość pola typu SERIAL po wykonaniu insert'u?
4.15.3) Czy użycie currval() i nextval() nie doprowadzi do "race condition" z innymi użytkownikami?
4.15.4) Dlaczego numery sekwencji nie są ponownie używane przy przerwaniu transakcji? Skąd się biorą luki w numerowaniu kolumny tabeli sekwencjami/SERIALem?
4.16) Co to jest OID? Co to jest TID?
4.17) Jakie jest znaczenie niektórych terminów w PostgreSQL?
4.18) Skąd bierze się ten błąd: "ERROR: Memory exhausted in AllocSetAlloc()"?
4.19) Jak sprawdzić jakiej wersji PostgreSQL używam?
4.20) Dlaczego operacje, które wykonuję na dużych obiektach "large-object" zwracają komunikat: "invalid large obj descriptor"?
4.21) Jak stworzyć kolumnę której domyślną wartością będzie bieżący czas?
4.22) Dlaczego zapytania używające `IN` są takie wolne?
4.23) Jak wykonać "outer join"?
4.24) Jak wykonywać zapytanie używające kilku baz danych jednocześnie?
4.25) Jak zwrócić w funkcji wiele rzędów lub kolumn?
4.26) Dlaczego nie mogę w sposób pewny tworzyć/usuwać tabel tymczasowych w funkcjach PL/PgSQL?
4.27) Jakie są możliwości replikacji w PostgreSQL?
4.28) Jakie możliwości szyfrowania oferuje PostgreSQL?

## Rozwijanie PostgreSQL

5.1) Napisałem własną funkcję. Kiedy użyję jej w psql, program zrzuca pamięć (dump core)?
5.2) Jak mogę dodać/zgłosić nowe typy czy funkcje do PostgreSQL?
5.3) Jak napisać funkcję C zwracającą krotkę (tuple)?
5.4) Zmieniłem plik źródłowy. Dlaczego po rekompilacji nie widać zmiany?

## Pytania ogólne

#### 1.1) Co to jest PostgreSQL? Jak to wymawiać?

PostgreSQL wymawia się Post-Gres-kju-el. Często podczas rozmów używany jest termin "Postgres"

PostgreSQL jest rozszerzeniem systemu zarządzania bazami danych - POSTGRES, kolejną generacją rozwojowego prototypu DBMS. Mimo, że PostgreSQL zachował bardzo dobrze zbudowany model danych (data model) i bogaty zestaw typów danych POSTGRES'a, zastąpił PostQuel'owy język zapytań z rozbudowanym podzbiorem języka SQL. PostgreSQL jest oprogramowaniem darmowym z dostępnymi całymi źródłami.

Rozwój PostgreSQL jest prowadzony przez grupę ludzi z Internetu, komunikujących się poprzez mailowe listy dyskusyjne PostgreSQL. Obecnym koordynatorem jest Marc G. Fournier (scrappy@PostgreSQL.org). (Zobacz pytanie 1.6 jak się przyłączyć). Ta grupa ludzi jest odpowiedzialna za cały rozwój PostgreSQL. PostgreSQL jest projektem nie kontrolowanym przez żadną firmę, aby wziąć udział w jego rozwoju sprawdź, http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html

Autorami PostgreSQL 1.01 byli Andrew Yu and Jolly Chen. Wiele innych osób pomogło przy portowaniu, testowaniu, debugowaniu i rozwijaniu kodu. Oryginalny kod Postgresa, na którym został oparty PostgreSQL, był wysiłkiem studentów oraz pracowników pracujących pod kierownictwem profesora Michael'a Stonebraker'a z University of California w Berkeley.

Oryginalną nazwą oprogramowania w Berkeley był Postgres. Po dodaniu obsługi SQL w 1995, nazwa została zmieniona na Postgres95. Pod koniec roku 1996 nazwa została zmieniona na PostgreSQL.

#### 1.2) Jaką licencją chroniony jest PostgreSQL?

PostgreSQL objęty jest następującą licencją:

PostgreSQL Data Base Management System

Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group Portions Copyright (c) 1994-6 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Tekst powyżej, jest klasyczną licencją BSD. Nie posiada ona żadnych restrykcji co do używania kodu źródłowego. Podoba nam się i nie zamierzamy jej zmieniać.

#### 1.3) Na jakich systemach Unixowych działa PostreSQL?

PostgreSQL powinien działać na wszystkich nowych Unix-podobnych systemach. Platformy, które zostały szczegółowo przetestowane podczas publikowania PostgreSQL są wymienione w dokumentacji opisującej instalację.

#### 1.4) Na jakich nie-Unixowych systemach działa PostgreSQL?

Klient

Możliwa jest kompilacja bibliteki C libpq, psql oraz innych interfejsów i uruchamianie ich na platformie MS Windows. W tym wypadku klient jest uruchamiany na MS Windows a z serwerem komunikuje się poprzez TCP/IP. Serwer może działać na dowolnej wspieranej platformie Unixowej. Plik win32.mak jest dołączony do źródeł, aby można było stworzyć bibliotekę libpq oraz program psql działające w środowisku Win32. PostgreSQL może się także komunikować z klientami ODBC.

Serwer

Serwer może być uruchamiany na Windows NT i Win2k używając bibliotek Cygwin, Cygnus Unix/NT. W pliku pgsql/doc/FAQ_MSWIN znajdującym się w źródłach lub pod adresem: http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN na naszych stronach.

Obecnie prowadzone są prace nad stworzeniem wersji dla MS Win NT/200/XP. Jeśli chcesz się dowiedzieć o obecnym statusie tych prac zobacz http://techdocs.postgresql.org/guides/Windows and http://momjian.postgresql.org/main/writings/pgsql/win32.html.

Istnieje także port pod Novell Netware 6 dostępny pod adresem http://forge.novell.com.

#### 1.5) Skąd można ściągnąć PostgreSQL?

Główny serwer ftp z dostępem "anonymous" dla PostgreSQL znajduje się ftp://ftp.PostgreSQL.org/pub. jeśli szukasz mirrorów sprawdź naszą główną stronę www.

#### 1.6) Gdzie można szukać wsparcia technicznego?

Adres głównej listy mailowej: pgsql-general@PostgreSQL.org. Jest ona przeznaczona dyskusjom dotyczącym spraw związanych z PostgreSQL. Żeby zapisac się na listę, wyślij email z następującymi liniami w treści maila (nie w temacie):

        subscribe
        end

na adres: pgsql-general-request@PostgreSQL.org.

Dostępna jest także lista wysyłająca digesty. Aby zapisać się na nią, wyślij email na adres: pgsql-general-digest-request@PostgreSQL.org z treścią maila zawierającą:

        subscribe
        end

Digesty są wysyłane do członków listy, kiedy na główną listę dotrze ok 30k wiadomości.

Dostępna jest także lista poświęcona błędom znalezionym w PostgreSQL. Aby zapisać się na nią wyślij email na adres: pgsql-bugs-request@PostgreSQL.org z treścią maila zawierającą:

        subscribe
        end

Lista poświęcona dyskusjom developerów jest dostępna pod adresem: pgsql-hackers-request@PostgreSQL.org Aby się na nią zapisać wyślij na jej adres mail z treścią:

        subscribe
        end

Dodatkowe informacje o listach mailowych dotyczących PostgreSQL można znaleźć na stronach WWW PostgreSQL pod adresem:

> http://www.PostgreSQL.org

W sieci EFNet istnieje kanał IRC #PostgreSQL. Ja, do połączenia się z kanałem używam Unixowego polecenia `irc -c '#PostgreSQL' "$USER" irc.phoenix.net.`

Lista firm oferujących wsparcie na zasadach komercyjnych znajduje się pod adresem: http://techdocs.postgresql.org/companies.php.

#### 1.7) Jaka jest ostatnia dostępna wersja?

Ostatnia dostępna wersja PostgreSQL to 7.4.1.

Planujemy publikowanie kolejnych wersji co sześć do ośmiu miesięcy.

#### 1.8) Jaka dokumentacja jest dostępna?

Kilka manuali, stron podęcznika man, oraz kilka przykładów do testowania są załączone w samej dystrybucji. Znajdują się one w katalogu /doc. Manual może być także przeglądany poprzez strony www pod adresem http://www.PostgreSQL.org/docs.

Istnieją także dwie książki dostępne online pod adresami http://www.PostgreSQL.org/docs/awbook.html i http://www.commandprompt.com/ppbook/. Lista książek o PostgreSQL, które można kupić znajduje się pod adresem http://techdocs.PostgreSQL.org/techdocs/bookreviews.php. Zbiór technicznych artykułów o PostgreSQL znajduje się pod adresem http://techdocs.postgresql.org/.

psql posiada kilka wbudowanych poleceń \d, za pomoca których można sprawdzić informacje dotyczące typów, operatorów, funkcji, agregatów itd.

Na naszej stronie można znaleźć dużo więcej dokumentacji.

#### 1.9) Gdzie można znaleźć informację o znanych błędach czy brakujących rozwiązanich?

PostgreSQL wspiera rozszerzony podzbiór standardu SQL-92. Sprawdź naszą listę TODO aby znaleźć informację o znanych problemach, brakujących rozwiązaniach czy przyszłych planach.

#### 1.10) Jak mogę się nauczyć SQL?

Książka o PostgreSQL http://www.PostgreSQL.org/docs/awbook.html uczy SQL. Jest jeszcze inna ksiązka o PostgreSQL dostępna pod adresem: http://www.commandprompt.com/ppbook. Dobry tutorial możesz znaleźć pod adresem: http://www.intermedia.net/support/sql/sqltut.shtm, oraz http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, i http://sqlcourse.com.

Jeszcze inny to "Teach Yourself SQL in 21 Days, Second Edition" pod adresem: http://members.tripod.com/er4ebus/sql/index.htm

Wielu z naszych użytkowników poleca The Practical SQL Handbook, Bowman, Judith S., et al., Addison-Wesley. Inni polecają The Complete Reference SQL, Groff et al., McGraw-Hill.

#### 1.11) Czy PostgreSQL ma rozwiązany problem Y2K?

Tak, bez problemu radzimy sobie z datami po roku 2000 AD, oraz przed rokiem 2000 BC.

#### 1.12) Jak mogę się przyłączyć do grupy osób bezpośrednio pracujących nad rozwojem PostgreSQL?

Przede wszystkim ściągnij ostatnie dostępne źródła i przeczytaj dokumentację przeznaczoną dla developerów na naszej stronie www lub dostępną także w źródłach PostgreSQL. Następnie zapisz się na listy mailowe pgsql-hackers i pgsql-patches. I na koniec, wysyłaj nam wysokiej jakości patch'e na listę pgsql-patches.

Jest około 12 osób, które mają uprawnienia do commit'owania w CVS PostgreSQL'a. Każdy z nich submitował tak wiele wysokiej jakości patchy, że stało się niemożliwe dla obecnych commiterów być z nimi na bieżąco, więc musieliśmy im ufać i mieć pewność, że ich poprawki są wysokiej jakości.

#### 1.13) Jak mogę zgłaszać błędy?

Zajrzyj na stronę PostgreSQL BugTool, na której opisane są wskazówki jak zgłaszać informacje o błędach.

Zajrzyj także na nasz ftp ftp://ftp.PostgreSQL.org/pub, aby sprawdzić czy nie ma nowszych wersji PostgreSQL czy patchy.

#### 1.14) Jak można porównać PostgreSQL w stosunku do innych DBMS?

Jest kilka sposobów oceny softwaru: możliwości, wydajność, stabilność, wsparcie i cena.

Możliwości
  PostgreSQL posiada możliwości dostępne w dużych, komercyjnych systemach DBMS, takie jak transakcje, podzapytania (subselects), triggery, widoki, klucze obce, referential integrity, oraz wyrafinowany system blokowania. Mamy także właściowści których inni nie posiadają, jak typy definiowane przez użytkownika, dziedziczenie, rules, multi-version concurrency control, która redukuje problemy z blokowaniem (lock contention).
Wydajność
  Wydajność PostgreSQL jest podobna do innych komercyjnych i open source baz danych. W niektórych sytuacjach jest szybszy w niektórych wolniejszy. W porównianiu do MySQL lub mniejszych baz danych jesteśmy szybsi przy wielu użytkownikach, skomplikowaych zapytaniach i dużym obciążeniu podczas. MySQL jest szybszy dla prostych SELECTów wykonywanych przez niewielu użytkowników. Spowodowane jest to narzutem, który się pojawia przy transakcjach. Oczywiście MySQL nie ma większości z rozwiązań opisanych powyżej w sekcji Możliwości . PostgreSQL został stworzony z myślą o stabilności, oraz szerokiej gamie możliwości, ale mimo to staramy się w każdej wersji poprawiać jego wydajność. Ciekawe porównanie PostgreSQL i MySQL można znaleźć pod adresem http://openacs.org/philosophy/why-not-mysql.html Dodatkowo, MySQL jest firmą, która dystrybuuje jej produkty poprzez zasadę Open Source i wymaga wykupienia licencji w przypadku tworzenia close-source software, co ie ma miejsca w przypadku PostgreSQL.
Stabilność
  Zdajemy sobie sprawę, że DBMS musi być stabilny, w przeciwnym wypadku jest bez wartości. Staramy się publikować kod stabilny, dobrze przetestowany, z minimum możliwych błędów. Każde wydanie poprzedza co najmniej miesiąc testów wersji beta. Patrząc na historię wydań PostgreSQL widać, że dostarczamy stabilne, dobrze sprawdzone wersje, które są gotowe do użycia w środowisku produkcyjnym. Myślimy, że proces publikowania kolejnych wersji opracowany przez nas jest jednym z lepszych wśród innych twórców oprogramowania bazodanowego.
Wsparcie
  Dzięki naszym listom mailowym masz dostęp do dużej liczby programistów i użytkowników, którzy pomagają rozwiązać każdy napotkany problem. Chociaż nie możemy gwarantować znalezienia rozwiązania danego problemu, nie różnimy się w tym od innych komercyjnych systemów DBMS. Bezpośredni kontakt z programistami, użytkownikami, dokumentacją i kodem źródłowym sprawiają, że wsparcie oferowane PostgreSQL niejednokrotnie jest lepsze niż w innych systemach DBMS. Istnieje także możliwość skorzystania z komercyjnego wsparcia dla tych, których takiego rozwiązania potrzebują. (Sprawdź ten punkt FAQ.)
Cena
  Korzystanie z PostgreSQL jest darmowe, zarówno w przypadku komercyjnym jak i niekomercyjnym. Możesz korzystać z naszego kodu źródłowego w Twoim produkcie bez żadnych ograniczeń, poza tymi wymienionymi w licencji BSD przytoczonej powyżej.

#### 1.15) W jaki sposób mogę wesprzeć finansowo PostgreSQL?

PostgreSQL korzysta z najlepszej infrastruktury od samego początku istnienia projektu, czyli roku 1996 kiedy rozpoczeliśmy pracę. Wszystko to zawdzięczamy Marc'owi Fournier'owi, który stworzył tą infrastrukturę i zarządza nią od lat.

Wysokiej jakości infrastruktura jest bardzo ważna dla każdego projektu open-source. Zapobiega przerwom w rozwoju projektu i jakimkolwiek przestojom.

Oczywiście korzystanie z wysokiej jakości infrastruktury nie jest tanie. Istnieje wiele różnych miesięcznych, czy jednorazowych wydatków, które trzeba ponosić aby wszystko działało jak należy. Jeśli Ty, bądź Twoja firma może wspomóc finansowo rozwój PostgreSQL odwiedź adres: http://store.pgsql.com/shopping/ gdzie opisane jest jak to zrobić.

Chociaż na stronie wspomniana jest nazwa PostgreSQL Inc, "datki" są przeznaczone jedynie na rozwój projektu PostgreSQL i nie są przeznaczane na finansowanie jakiejkolwiek firmy. Jeśli wolisz, możesz wysłać czek na adres kontaktowy.

Jeśli możesz się pochwalić udanymi wdrożeniami PostgreSQL, prosimy abyś zgłosił nam to na stronie: http://advocacy.postgresql.org.

## User Client Questions

#### 2.1) Czy są jakieś driwery ODBC dla PostgreSQL?

Dostępne są dwa driwery ODBC: PsqlODBC i OpenLink ODBC.

Możesz pobrać PsqlODBC z adresu http://gborg.postgresql.org/project/psqlodbc/projdisplay.php

OpenLink ODBC może być pobrany z adresu: http://www.openlinksw.com. Współpracuje ze standardowym oprogramowaniem klienckim ODBC więc w ten sposób możesz korzystać z PostgreSQL ODBC dostępnego na każdej pltaformie którą wspiera (Win, Mac, Unix, VMS).

Autorzy będą prawdopodobnie sprzedawać ten produkt osobom które wymagają komercyjnego wsparcia, ale wersja darmowa będzie zawsze dostępna. Wszystkie pytania możesz wysyłać na adres: postgres95@openlink.co.uk.

#### 2.2) Jakie istnieją narzędzia pozwalające na dostęp do PostgreSQL przez www?

Dobry podręcznik dla początkujących o dostępie do bazy danych przez www możesz znaleźć pod adresem: http://www.webreview.com

Do integracji z www, świetnym rozwiązaniem jest PHP. Możesz znaleźć więcej informacji na ten temat pod adresem http://www.php.net.

Wiele osób w przypadku skomplikowanych rozwiązań uzywa Perl'a i modułu CGI.pl lub mod_perl.

#### 2.3) Czy istnieje jakieś GUI dla PostgreSQL?

Tak, istnieje kilka interfejsów graficznych dla PostgreSQL. Wśród nich PgAccess ( http://www.pgaccess.org), PgAdmin III (http://www.pgadmin.org), RHDB Admin (http://sources.redhat.com/rhdb/ ) oraz Rekall ( http://www.thekompany.com/products/rekall/, komercyjny). Istnieje także PHPPgAdmin ( http://phppgadmin.sourceforge.net/ ), webowy interfejs dla PostgreSQL.

Więcej informacji na ten temat znajduje się pod adresem See http://techdocs.postgresql.org/guides/GUITools.

#### 2.4) Za pomocą jakich języków programowania można się komunikować z PostgreSQL?

Najbardziej popularne języki posiiadają własny interfejs dla PostgreSQL. Sprawdź listę rozszerzeń dla intersującego Ciebie języka programowania.

Ze źródłami PostreSQL dystrubuowane są interfejsy dla następujących języków programowania:

- C (libpq)
- Embedded C (ecpg)
- Java (jdbc)
- Python (PyGreSQL)
- TCL (libpgtcl)

Inne interfejsy są dostępne pod adresem: http://gborg.postgresql.org w sekcji Drivers/Interfaces.

## Pytania dotyczące administracji

#### 3.1) Jak mogę zainstalować PostgreSQL w innej lokalizacji niż /usr/local/pgsql?

Użyj opcji --prefix podczas uruchamiania skryptu configure.

#### 3.2) Podczas startu postmaster'a, otrzymuję komunikat o błędzie: Bad System Call lub "core dumped". Dlaczego?

Ten błąd może być wynikiem wielu problemów, ale na początek sprawdź czy masz zainstalowane rozszerzenia systemu V w jądrze systemu. PostgreSQL wymaga do pracy zainstalowanej obsługi pamięci dzielonej i semaforów.

#### 3.3) Podczas startu postmaster'a, otrzymuję komunikat o błędzie: IpcMemoryCreate. Dlaczego?

Albo nie masz poprawnie skonfigurowanej obsługi pamięci dzielonej w jądrze systemu, albo musisz zwiększyć jej dostępny rozmiar. Dokładna ilość jaką potrzebujesz jest zależna od architektury systemu na jakim pracujesz, jak dużo buforów oraz jak dużo procesów backendu skonfigurowałeś dla postmaster'a. Dla większości systemów, z domyślną liczbą buforów i procesów potrzebujesz minimum w przybliżeniu 1MB. Zobacz PostgreSQL Administrator's Guide gdzie szczegółowo zostało opisane wykorzystanie pamięci dzielonej i semaforów.

#### 3.4) Podczas startu postmaster'a, otrzymuję komunikat o błędzie: IpcSemaphoreCreate. Dlaczego?

Jeśli treść błędu brzmi: IpcSemaphoreCreate: semget failed (No space left on device) oznacza to, że jądro systemu nie jest skonfigurowane do obsługi wystarczającej liczby semaforów. Postgres wymaga jednego semafor'a na potencjalny jeden proces backend. Tymczasowym rozwiązaniem jest uruchomienie programu postmaster z mniejszą maksymalną liczbą procesów backend. Użyj opcji -N z parameterem mniejszym od domyślnego - 32. Bardziej trwałym rozwiązaniem jest zwiększenie parametrów SEMMNS i SEMMNI jądra twojego systemu.

Niedziałające semafory mogą spowodować niepoprawne zamknięcie systemu w czasie intensywnego korzystania z bazy.

Jeśli treść błędu jest inna, może to oznaczać, że obsługa semaforów nie została włączona do jądra wcale. Zobacz PostgreSQL Administrator's Guide po bardziej szczegółowe informacje o pamięci dzielonej i semaforach.

#### 3.5) W jaki sposób mogę kontrolować połączenia z innych hostów?

Domyślnie PostgreSQL pozwala jedynie na połączenia za pomocą socketów Unixowych z lokalnego hosta. Inne hosty nie będą mogły się połączyć z serwerem dopóki nie zostanie dodana opcja -i do postmaster'a, oraz nie umożliwi się autoryzacji na podstawie adresu hostów modyfikując odpowiednio plik $PGDATA/pg_hba.conf. To zmiany pozwolą na połączenia TCP/IP.

#### 3.6) Jak powinienem skonfigurować system baz danych aby uzyskać lepszą wydajność?

Indeksy bez wątpienia mogą przyspieszyć wykonywanie zapytań. Polecenie EXPLAIN pozwala zobaczyć jak PostgreSQL interpretuje Twoje zapytanie i które indeksy są używane.

Jeśli wykonujesz bardzo dużo INSERTów, może warto je wykonać za pomocą jednego dużego pliku używając polecenia COPY. Jest to dużo szybsze niż pojedyncze INSERTy. Po drugie polecenia SQL nie zawarte w bloku określającym transakcję - BEGIN WORK/COMMIT, są traktowane jako pojedyncza transakcja. Rozważ wykonanie kilku poleceń/zdań SQL w jednym bloku transakcji. To redukuje narzut nakładany przez transakcję. Przy dużych zmianach w danych, warto usunąć i stworzyć na nowo indeksy.

Jest kilka opcji pozwalających na poprawienie wydajności. Możesz wyłączyć fsync() poprzez uruchomienie postmaster'a z opcjami -o -F. To spowoduje, że fsync() nie będzie zrzucał danych na dysk po każdej transakcji.

Możesz także uruchomić postmaster'a z opcją -B aby zwiększyć wielkość pamięci dzielonej używanej przez procesy backendów. Jeśli ustawisz tą wartość zbyt wysoko i przekroczysz limity ustawione przez kernel na pamięć dzieloną, postmaster może się nie uruchomić. Każdy bufor zajmuje 8K a domyślna ilość buforów to 64.

Możesz także użyć opcji -S dla backendu aby zwiększyć maksymalną wartość pamięci używaną przez proces backendu podczas sortowania. Opcja -S jest ustawiana wartością podawaną w kilobajtach, domyślna wartość to 512K.

Możesz także użyć polecenia CLUSTER aby pogrupować dane w tabelach wg indeksu. Zobacz opis polecenia CLUSTER w manualu żeby dowiedzieć się więcej.

#### 3.7) Jakie są możliwości wyszukiwania błędów?

PostgreSQL ma kilka możliwości na raportowanie informacji o jego statusie, które mogą być przydatne przy debugowaniu procesu.

Przede wszystkim uruchom skrypt configure z opcją --enable-cassert, wiele funkcji assert() monitorują postęp procesu backend i zatrzymują program kiedy wydarzy się coś nieoczekiwanego.

Zarówno postmaster jak i postgres mają kilka opcji do debugowania. Za każdym razem kiedy uruchamiasz postmaster'a, upewnij się, że wysyłasz standardowe wyjście i error do pliku z logami, np. w ten sposób:

        cd /usr/local/pgsql
        ./bin/postmaster >server.log 2>&1 &

To utworzy plik server.log w głównym katalogu PostgreSQL. Ten plik zawiera pożyteczne informacje o problemach i błędach, które wydarzyły się podczas pracy serwera. Postmaster posiada opcję -d, która pozwala na raportowanie bardzo szczególowych informacji. Do opcji -d podajemy liczbę, która określa szczegółowość wysyłanych informacji. Musisz mieć świadomość, że wysoki poziom logowania będzie powodował tworzenie bardzo duzych plików z logami.

Jeśli postmaster nie został uruchomiony, możesz uruchomić postgres'owy backend z linii poleceń, i uruchomić Twoje polecenie SQL bezpośrednio na nim. Taki sposób jest polecany jedynie w przypadku debugowania. Zwróć uwagę, że w tym wypadku zapytanie kończy znak nowej linii a nie średnik. Jeśli skompilowałeś z opcjami debugowania mozesz użyć debuggera aby sprawdzić co się dzieje. Poniewż backend nie został uruchomiony przez postmaster'a, nie działa w identycznym środowisku, co oznacza że powtórzenie warunków w jakich wystąpiły problemy moze być problemem.

Jeśli postmaster działa, uruchom psql w jednym z okien, następnie znajdź PID procesu postgres używanego przez psql. Użyj debuggera aby do PID'u postgres'a. Możesz ustawiać pułapki (breakpoints) w debuggerze i wykonywać zapytania z psql. Jeśli debugujesz uruchamianie postgres'a, możesz ustawić zmienną PGOPTIONS="-W n", następnie uruchomić psql. Opcja ta pozwoli spowolnić uruchomienie na n sekund abyś mógł się połączyć z procesem za pomocą debugera, ustawić jakiekolwiek pułapki i kontynuować proces uruchamiania.

postgres może być uruchamiany z opcjami -s, -A i -t, które mogą być bardzo przydatne przy debuggowaniu i ocenie wydajności.

Możesz także skompilować z profilingiem aby zobaczyć jakie funkcje ile czasu wykonują się. Pliki profilowane dla backendu zostaną umieszczone w katalogu pgsql/data/base/dbname. Pliki profilu klienta zostaną umieszczone w bieżącym katalogu klienta. Linux wymaga aby kompilować z opcją -DLINUX_PROFILE aby profilowanie odbywało się poprawnie.

#### 3.8) Skąd się bierze komunikat: "Sorry, too many clients" podczas próby połączenia się z bazą danych?

Musisz zwiększyć limit ilości jednoczesnych procesów bacekendu dla procesu postmaster'a.

Domyślny limit to 32 procesy. Możesz go zwiększyć przez restart postmaster z odpowiednią wartością ustawianą opcję -N w pliku postgresql.conf.

Weź pod uwagę, że jeśli zwiększysz wartość podaną w opcji -N na więcej niż 32 musisz także zwiększyć wartość w opcji -B ponad jej domyślną wartość 64; wartość -B musi być co najmniej dwa razy większa od wartości podanej w opcji -N, a prawdopodobnie powinna być w rzeczywistości jeszcze większa dla optymalnej wydajności. Dla dużej liczby procesów backendu na pewno zauważysz, że trzeba zwiększyć różne parametry jądra Unixa. Rzeczy, które pownieneś sprawdzić to maksymalna liczba bloków pamięci dzielonej, SHMMAX; maksymalna liczba semaforów, SEMMNS oraz SEMMNI; maksymalna liczba procesów, NPROC; maksymalna liczba procesów na jednego użytkownika, MAXUPRC; i maksymalna liczba otwartych plików, NFILE oraz NINODE. Powód dla którego PostgreSQL ma limit na maksymalną liczbę procesów backendu to obawa o wyczerpanie zasobów systemu.

#### 3.9) Jakie pliki znajdują się w pg_temp?

Katalog ten zawiera tymczasowe pliki utworzone przez executor. Dla przykładu, jeśli jakaś operacja sortowania jest wymagana do wykonania ORDER BY, a samo sortowanie wymaga więcej miejsca niż parametr backendu -S ustawił do wykorzystania, wtedy tymczasowe pliki są używane do przechowywania tych danych.

Pliki tymczasowe powinny być usunięte automatycznie, ale mogło się to nie stać jeśli proces backendu w międzyczasie nie zakończył się poprawnie podczas operacji sortowania. Jeśli w danym momencie nie działają żadne procesy backendów mozesz spokojnie usunąć pliki pg_tempNNN.NN.

#### 3.9) Dlaczego konieczne jest przy upgradzie PostgreSQL korzystanie ze skryptów dump i restore?

Twórcy PostgreSQL dokonują jedynie małych zmian pomiędzy małymi upgradami wersji, np z 7.2 do 7.2.1, wtedy upgrade nie wymaga korzystania z dump i restore. Przy większych zmianach, np. z wersji 7.2 do 7.3, często zmianymają wpływ na format przechowywanych danych. Zmiany te są na tyle skomplikowane, że nie utrzymujemy zgodości z poprzednimi wersjami PostgreSQL. dump pozwala na wydostanie danych w takiej postaci, w której łatwe jest ich zaimportowanie do nowszych wersji bez kłopotu.

W wydaniach gdzie zmiany nie dotyczą formatu danych na dysku, można wykorzystać skryptu pg_upgrade, do upgradu bez użycia dump/restore. Dokumentacja do danego wydania zawiera informację czy możliwe jest użycie pg_upgrade.

## Pytania dotyczące używania

#### 4.1) Jaka jest różnica pomiędzy kursorami binarnymi (binary cursors) i zwykłymi kursorami (normal cursors)?

Zobacz w manualu opis polecenia DECLARE.

#### 4.2) Jak mogę pobrać za pomocą SELECT jedynie kilka pierwszych wyników zapytania?

Zobacz w manualu opis polecenia FETCH lub użyj polecenia SELECT ... LIMIT....

Nawet jeśli chesz pobrać kilka pierwszych rzędów z wyniku zapytania, całe zapytanie musi zostać wykonane. Byc może powinieneś skorzystać z polecenia ORDER BY. Jeśli istnieje indeks który odpowiada polom określonym przez ORDER BY, PostgreSQL może wykorzystać jedynie kilka pierwszych rzędów, być może będzie konieczność wykonania zapytania do momentu aż zostaną znalezione pożądane wyniki.

Aby otrzymać losowy rząd, użyj:

        SELECT col
        FROM tab
        ORDER BY random()
        LIMIT 1;

#### 4.3) Jak mogę uzyskać listę wszystkich tabel czy innych rzeczy pod psql?

Możesz sprawdzić zawartość źródeł psql, a konkretnie plik pgsql/src/bin/psql/describe.c. Zawiera on polecenia SQL które generuja wyniki komend z backslashem. Możesz także uruchomić psql z opcją -E wtedy po wykonaniu polecenia z backslashem wyświetlane będzie zapytanie, które w rzeczywistości jest wykonywane.

#### 4.4) Jak usunąć kolumnę z tabeli lub zmienić jej typ?

DROP COLUMNT zostało dodane w wersji 7.3 przy poleceniu ALTER TABLE DROP COLUMN. We wcześńiejszych wersjach możesz zrobić tak:

    	 BEGIN;
    	 LOCAL TABLE old_table;
        SELECT ...  -- wybierz wszystkie kolumny poza tą jedną której chcesz się pozbyć
        INTO TABLE new_table
        FROM old_table;
        DROP TABLE old_table;
        ALTER TABLE new_table RENAME TO old_table;

Aby zmienić typ danych kolumny możesz zrobić tak:

       BEGIN;
       ALTER TABLE tab ADD COLUMN new_col new_data_type;
       UPDATE tab SET new_col = CAST(old_col AS new_data_type);
       ALTER TABLE tab DROP COLUMN old_col;
       COMMIT;

#### 4.5) Jaki jest maksymalny rozmiar dla rzędu, tabeli i bazy danych?

Oto wszystkie ograniczenia:

        Maksymalny rozmiar dla bazdy danych?     nieograniczony ( istnieją
    	 bazy danych o wielkości 32 TB databases )
        Maksymalny rozmiar dla tabeli?           32 TB
        Maksymalny rozmiar dla rzędu?            1.6 TB
        Maksymalny rozmiar pola?                 1 GB
        Maksymalna liczba rzędów w tabeli?       nieograniczona
        Maksymalna liczba kolumn w tabeli?       250-1600 w zależoności od typów kolumn
        Makasymalna liczba indeksów na tabeli?   nieograniczona

Oczywiście "nieograniczony" nie jest prawdą tak do końca, istnieją ograniczenia wynikające z dostępnego miejsca na dysku, pamięci/swapa. Kiedy wielkości te będą bardzo duże może odbić się to na wydajności.

Maksymalny rozmiar tabeli, czyli 32 TB nie wymaga od systemu operacyjnego wsparcia dla dużych plików. Duże tabele są przechowywane jako pliki o rozmiarze 1 GB, więc ograniczenia co do wielkości plików narzucone przez system plików nie są istotne.

Masymalny rozmiar tabeli i maksymalna liczba kolumn może być zwiększona jeśli zwiększymy domyślny rozmiar bloku (block size) do 32k.

#### 4.6) Jak dużo miejsca w bazie danych jest konieczne aby przechowywać dane ze zwyczajnego pliku tekstowego?

Baza danych PostgreSQL może potrzebować do pięciu razy więcej miejsca na przechowywanie danych z plików tekstowych niż ich objętość.

Jako przykład możemy rozważyć plik składający się z 100,000 linii zbudowanych z liczby całkowitej oraz opisu tekstowego w każdej. Załóżmy, że średnio każdy łańcuch tekstu w linii zajmuje 20 bajtów. Cały plik powinien zajmować ok. 2.8 MB. Rozmiar pliku bazy danych w PostgreSQL zawierającego te dane mozna oszacować na około 6.4MB:

        36 bajtów: nagłówek każdego rzędu w przybliżeniu)
        24 bajty:  jedno pole int i jedno pole typu text
       + 4 bajty:  wkaźnik na stronie do krotki
       --------------------------------------------------
        64 bajty w jednym rzędzie

    	Strona danych w PostgreSQL zajmuje 8192 bajtów (8 KB), więc:

       8192 bajtów na stronę
       ---------------------   =  128 rzędów na jedną strone w bazie (zaokrąglone w dół)
         64 bajtów na rząd

       100000 rzędów danych
       -----------------------  =  782 stron w bazie danych (zaokrąglone w górę)
          128 rzędów na stronę

    782 stron w bazie * 8192 bajtów na stronę  =  6,406,144 bajtów (6.4 MB)

Indeksy nie powodują dużego narzutu na zajmowane miejsce, ale zawierają pewne dane, więc w pewnych przypadkach moga być całkiem duże.

NULLe są przechowywane jako mapy bitowe, więc używają bardzo mało miejsca.

#### 4.7) Jak mogę sprawdzić jakie tabele, klucze, bazy danych i użytkownicy są utworzeni?

psql ma całkiem dużą ilość poleceń z backslashem aby wydobyć takie informacje. Wprowadź \? aby zobaczyć ich spis. Istnieją także tablice systemowe rozpoczynające się od pg_, zawierające interesujące Ciebie informacje. Wykonanie psql -l pokaże spis wszystkich baz danych.

Obejrzyj także plik pgsql/src/tutorial/syscat.source. Zawiera on wiele z zapytań typu SELECT, które są potrzebne aby wydobyć informacje z tablic systemowych.

#### 4.8) Moje zapytania są wolne lub nie używają kluczy. Dlaczego?

Indeksy nie są używane automatycznie przez kążde z zapytań. Ideksy są używane jedynie gdy tabela jest odpowiedniego rozmiaru, większego niż wymagany minimalny, a zapytanie wybiera jedynie mały procent zawartości tabeli. Wynika to z tego, że losowy dostep do dysku powodowany przez ideksowane poszukiwanie jest czasami wolniejsze niż poszukiwanie sekwencyjne bez użycia kluczy.

Żeby zdecydować czy indeks powinien byc używany, PostgreSQL musi mieć statystyki dotyczące danej tabeli. Są one gromadzone przez użycie polecenia VACUUM ANALYZE, lub poprostu ANALYZE. używając statystyk, optymalizator wie ile rzędów jest w tabeli i może lepiej określić czy indeksy powinny być użyte. Statystyki mogą być także pomocne w określeniu najlepszej kolejności wykonania złączenia (join) i jego sposobu. Gromadzenie statystyk powinno się odbywać w określonych interwałach czasu ponieważ dane w tabelach zmieniają się.

Indeksy nie są zazwyczaj używane przez ORDER BY lub przy wykonywaniu złączeń (join). Sekwencyjne przeszukiwanie po którym następuje sortowanie jest zazwyczaj szybsze nię wyszukiwanie za pomocą indeksu na dużej tabeli.

Jakkolwiek LIMIT w połączeniu z ORDER BY często będzie wykorzystywał indeksy ponieważ jedynie mała część z tabeli jest zwracana. W rzeczywistości, chociaż MAX() i MIN() nie używają indeksów, możliwe jest aby zwrócić te wartości używając indeksów poprzez użycie ORDER BY i LIMIT.

        SELECT col
        FROM tab
        ORDER BY col [ DESC ]
        LIMIT 1;

Jeśli uważasz, że optimizer myli się wybierając sequential scan, użyj SET enable_seqscan TO 'off' i uruchom testy aby sprawdzić czy wtym wypadku zapytanie będzie szybciej wykonywane.

Kiedy używa się operatorów dopasujących takich jak LIKE lub ~, indeksy będą używane jedynie w pewnych wypadkach:

- Początek wyszukiwania jest oparty na początku łańcucha tekstu.
  - wzorce LIKE nie mogą się zaczynać %
  - dopasowania operatorem ~ (dopasowania regularne) muszą się zaczynać znakiem specjalnym ^.
- Początek wyszukiwania nie może się zaczynać od klas znaków, np. [a-e].
- Case-insensitive searches such as ILIKE and ~* do not utilise indexes. Instead, use functional indexes, which are described in section 4.12.
- Standardowe locale C musi być uzyte przy wykonywaniu initdb

#### 4.9) Jak mogę sprawdzić w jakis sposób "query optimizer" wykonuje moje zapytanie?

Zobacz manual dla polecenia EXPLAIN.

#### 4.10) Co to jest "R-tree index"?

Indeks R-tree jest używany do indeksowania danych przestrzennych. Indeks hasuujący nie nadaje się do wyszukiwania odległości. Natomiast indeks typu B-tree może wyszukiwać odleglości jedynie w jednowymiarowych przestrzeniach. R-tree indeks radzi sobie z przestrzeniami wielo-wymiarowymi. Dla przykładu, jeśli zostanie założony indeks typu R-tree na polu typu point, system może bardziej wydajnie odpowiadać na zapytania typu "select all points within a bounding rectangle."

Źródłowym dokumentem opisującym oryginalnie projektowanie R-tree indeksów jest:

Guttman, A. "R-trees: A Dynamic Index Structure for Spatial Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.

Ten dokument możesz znaleźć także w pracy Stonebraker'a "Readings in Database Systems".

Wbudowane indeksy R-trees radzą sobie w wielobokami i boxes. Teoretycznie, indeksy R-tree mogą być rozszerzone o możliwości indeksowania w więcej wymiarowych przestrzeniach. W praktyce, rozbudowa indeksów R-tree wymaga trochę pracy, a w tej chwili nie dysponujemy jakąkolwiek dokumentacją jak to zrobić.

#### 4.11) Co to jest "Genetic Query Optimizer"?

Moduł GEQO ma za zadanie przyspieszenie optymalizacji zapytań łącząc wiele tabel za pomocą algorytmów genetycznych (Genetic Algorithm (GA)). Pozwala na używanie dużych zapytań łączących tabele (join queries) bez wykorzystywania zasobożernego wyszukiwania.

#### 4.12) Jak mogę używać wyrażeń regularnych w zapytaniach i zapytań case-insensitive w wyrażeniach regularnych? Jak korzystać z indeksów dla zapytań case-insensitive?

Operator ~ moze być wykorzystywany do wyszukiwania za pomocą wyrażeń regularnych, a ~* do wyszukiwania case-insensitive z wyrażeniami regularnymi. Wariant case-insensitive dla LIKE został nazwany ILIKE.

Porównania case-insensitive są zazwyczaj wykonywane w następujący sposób:

        SELECT *
        FROM tab
        WHERE lower(col) = 'abc'

W tym wypadku standardowe indeksy nie będą używane. Możesz utworzyć indeks funkcyjny, poprzez:

        CREATE INDEX tabindex on tab (lower(col));

#### 4.13) Jak sprawdzić w zapytaniu czy pole ma wartość NULL?

Możesz to sprawdzić, testując wartość kolumny warunkiem IS NULL albo IS NOT NULL.

#### 4.14) Jaka jest różnica pomiędzy różnymi typami tekstowymi (character types)?

    Type            Nazwa wewnętrzna   Uwagi
    --------------------------------------------------
    VARCHAR(n)      varchar            rozmiar określa maksymalną długość, nie ma tutaj wypełniania
    CHAR(n)         bpchar             wypełniane pustymi znakami do podanej długości
    TEXT            text               bez limitu na długość łańcucha
    BYTEA           bytea              zmiennej długości tablica bajtów (null-byte safe)
    "char"          char            	  1 znak

Jeśli będziesz przeglądać katalogi systemowe lub komunikaty o błędach często spotkasz się z podanymi powyżej nazwami wewnętrznymi.

Pierwsze cztery typy powyżej to tzw typy "varlena" (np. pierwsze cztery bajty na dysku to długość, po których jest data). Dlatego faktyczna długośc takiego łańcucha jest trochę większa niż zadeklarowany rozmiar. Te typy także podlegają kompresji lub mogą być przechowywane out-of-line jako TOAST, więc faktyczne zużycie miejsca na dysku może być mniejsze niż oczekiwane.

VARCHAR(n) jest najodpowiedniejszy do przechowywania łańcuchów o różnej długości ale określa on maksymalną jego długość. TEXT jest najlepszy dla łańcuchów o dowolnej długości, nie przekraczającej 1GB.

CHAR(n) jast najlepszym typem do przechowywania łańcuchów o tej samej długości. CHAR(n) wypełnia dane do żadanej długości, podczas gdy VARCHAR(n) przechowuje jedynie dane dostarczone. BYTEA służy do przechowywania danych binarnych, w szczególności dla danych zawierających NULL bajty. Wszystkie typy opisane tutaj maja podobne charakterystyki jeśli chodzi o wydajność.

#### 4.15.1) Jak mogę utworzyć pole które samo zwiększa swoją wartość?

PostgreSQL ma zaimplementowany typ SERIAL. Automatycznie tworzy sekwencję i indeks na tej kolumnie. Dla przykladu:

        CREATE TABLE person (
            id   SERIAL,
            name TEXT
        );

zostanie automatycznie prztłumaczone na:

        CREATE SEQUENCE person_id_seq;
        CREATE TABLE person (
            id   INT4 NOT NULL DEFAULT nextval('person_id_seq'),
            name TEXT
        );
        CREATE UNIQUE INDEX person_id_key ON person ( id );

Więcej informacji o sekwencjach znajdziesz w manualu o create_sequence. Możesz także użyć pola OID jako unikalnej wartości dla każdego rzędu danych. Jeśli będziesz potrzebował z backupować dane robiąc dump bazy i odtworzyć ją, musisz użyc pg_dump z opcją -o lub polecenia COPY WITH OIDS aby zachować OIDy.

#### 4.15.2) Jak pobrać wartość pola typu SERIAL po wykonaniu insert'u?

Jednym z podejść jest pobranie kolejnej wartości typu SERIAL z sekwencji za pomocą funkcji nextval() zanim zostanie wstawiona, a później należy jej użyć. Używając przykładu z tabeli z punktu 4.15.1, może to wyglądać w Perlu na przykład w ten sposób:

        new_id = output of "SELECT nextval('person_id_seq')"
        INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal');

Będziesz miał wtedy tą wartość przechowaną w zmiennej `new_id` do użytku w innych zapytaniach (np. jako klucz obcy do tabeli `person`). Warto zwrócić uwagę, że nazwa automatycznie utworzonej sekwencji SEQUENCE będzie następująca: <tabela>_<kolumnatypuserial>_seq, gdzie tabela i kolumnatypuserial są nazwami Twojej tabeli i Twojej kolumny typu SERIAL.

Inne rozwiązanie to użycie funkcji currval() na pola typu SERIAL po dodaniu nowej wartości do rzędu zawierającego kolumnę typu SERIAL z wstawioną domyślnie wartością, np.

        INSERT INTO person (name) VALUES ('Blaise Pascal');
        new_id = output of "SELECT currval('person_id_seq')";

Ostatecznie możesz użyć OID zwracanej po wykonaniu INSERT, chociaż to jest najmniej przenośne rozwiązanie. W Perlu, wykorzystując bibliotekę DBI z modułem Edmunda Mergla DBD::Pg, oid jest dostępny poprzez $sth->{pg_oid_status} po wykonaniu $sth->execute().

#### 4.15.3) Czy użycie currval() i nextval() nie doprowadzi do race condition z innymi użytkownikami?

Nie. currval() zwraca bieżącą wartość przypisaną przez Twój backend, a nie przez wszystkich użytkowników.

#### 4.15.4) Dlaczego numery sekwencji nie są ponownie używane przy przerwaniu transakcji? Skąd się biorą luki w numerowaniu kolumny tabeli sekwancjami/SERIALem?

Aby poprawić zbieżność (concurrency), wartości sekwencji są podawane działającym transakcjom kiedy tego potrzebują i nie są blokowane dopóki transakcja się nie zakończy. To spowoduje przerwy w numerowaniu z przerwanych transakcji.

#### 4.16) Co to jest OID? Co to jest TID?

OID są PostgreSQL'owym rozwiązaniem problemu unikalnych numerów rzędów. Każdy rząd tworzony przez PostgreSQL otrzymuje unikalny OID. Wszystkie OIDy generowane podczas procesu uruchamianego przez skrypt initdb mają mniejszą wartość niż 16384 (na podstawie pliku backend/access/transam.h). Wszystkie OIDy tworzone przez użytkownika sa równe lub większe podanej wcześniej wartości. Domyślnie wszystkie OIDy są unikalne nie tylko w pojedyńczej tabeli czy bazie danych ale w całej instalacji PostgreSQL.

PostgreSQL używa OIDów w swoim wewnętrznym systemie tabel, aby można było je łączyć. Te OIDy mogą byc używane aby identyfikowac rzędy w tabelach i wykorzystywać je w złączeniach tych tabel. Zaleca się abyś używał typu OID aby przechowywać wartości OID. Możesz utworzyć indeks na polu OID aby dostęp do niego był szybszy.

OID są przypisane do wszystkich rzędów z jednego głównego miejsca i używane sa przez wszystkie bazy danych. Jeśli chciałbyś zmienić OID na coś innego, lub jeśli chciałbyś zrobić kopię tabeli, z orginalnymi OIDami nie ma żadnego przeciwwskazania abyś to zrobił:

            CREATE TABLE new_table(old_oid oid, mycol int);
            SELECT old_oid, mycol INTO new FROM old;
            COPY new TO '/tmp/pgtable';
            DELETE FROM new;
            COPY new WITH OIDS FROM '/tmp/pgtable';

OIDy są przechowywane jako cztero-bajtowe liczby całkowite i skończą się po osiągnięciu czterech miliardów. Nikt jak dotąd nie zgłosił aby coś takiego się stalo, ale mamy zamiar pozbyć się tego ograniczenia zanim ktoś to zgłosi.

TID są używane aby zidentyfikować konkretne rzędy z blokami i wartością ofsetów. TIDy zmieniają się wraz ze zmianami rzędów. Sa używane przez indeksy, aby wskazywać do fizycznych rzędów.

#### 4.17) Jakie jest znaczenie niektórych terminów w PostgreSQL?

W części kodu źródłowego i starszej dokumentacji używamy terminów, które mają bardziej ogólne znaczenie. Oto niektóre z nich:

- table, relation, class
- row, record, tuple
- column, field, attribute
- retrieve, select
- replace, update
- append, insert
- OID, serial value
- portal, cursor
- range variable, table name, table alias

Listę terminów związanych z bazami danych możesz znaleźć pod tym adresem:http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glossary.html.

#### 4.18) Skąd bierze się ten błąd "ERROR: Memory exhausted in AllocSetAlloc()"?

Prawdopodobnie wyczerpała Ci się pamięć wirtualna (virtual memory) w systemie lub Twój kernel ma zbyt nisko ustawione limity dla pewnych zasobów. Spróbuj wykonać następujące polecenia zanim uruchomisz postmaster'a:

        ulimit -d 262144
        limit datasize 256m

W zależności od shell'a jakiego używasz jedno z tych poleceń może nie zadziałać, ale to ustawienie pozwoli ustawić segment danych dla procesu znacznie większy i być może pozwoli wykonać zapytanie. To polecenie zadziała dla bieżącego procesu oraz wszytkich podprocesów utworzonych po wykonaniu polecenia. Jeśli ten problem występuje z klientem SQL, ponieważ backend zwraca zbyt dużo danych, spróbuj wykonać to polecenie przed uruchomieniem klienta.

#### 4.19) Jak sprawdzić jakiej wersji PostgreSQL używam?

W psql, wpisz `select version();`

#### 4.20) Dlaczego operacje, które wykonuję na dużych obiektach "large-object" zwracają komunikat: "invalid large obj descriptor"?

Musisz użyć `BEGIN WORK` i `COMMIT` przed i po użyciu uchwytu do dużego obiektu, tzn. musisz nimi otoczyć funkcje `lo_open` ... `lo_close.`

Obecnie PostgreSQL używjąc "rule" zamyka uchwyt do dużego obiektu przy każdym wywołaniu "commit". Więc pierwsze próba zrobienia czegokolwiek z uchwytem spowoduje wypisanie: invalid large obj descriptor. Kod, który do tej pory działał (przynajmniej większość razy) będzie teraz generował informację o błędzie jeśli nie będziesz korzystał z transakcji.

Jeśli używasz interfejsu klienta jak ODBC być może będziesz musiał ustawić `auto-commit off.`

#### 4.21) Jak stworzyć kolumnę której domyślną wartością będzie bieżący czas?

Użyj CURRENT_TIMESTAMP:

    CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );

#### 4.22) Dlaczego zapytania używające `IN` sa takie wolne?

W wersjach wcześniejszych niż 7.4 łączymy podzapytania w outer queries poprzez sekwencyjne przeszukiwanie wyników podzapytania dla każdego rzędu z outer query. Jeśli podzapytanie zwraca jedynie kilka rzędów a zewnętrzne zapytanie zwraca ich wiele, IN jest najszybsze. Aby przyspieszyć inne zapytania można zastąpić `IN` przez `EXISTS`:

    SELECT *
        FROM tab
        WHERE col IN (SELECT subcol FROM subtab)

na:

    SELECT *
        FROM tab
        WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col)

Aby to rozwiązanie było szybkie, subcol powinna być kolumną indeksowaną.

W wersji 7.4 i późniejszych, IN w rzeczywistości używa tej samej wyrafinowanej techniki łączenia jak normalne zapytania i jest preferowane nad używaniem EXISTS.

#### 4.23) Jak wykonać "outer join"?

PostgreSQL ma zaimplementowane outer join wykorzystując standardową składnię SQL. Poniżej dwa przykłady:

        SELECT *
        FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);

or

        SELECT *
        FROM t1 LEFT OUTER JOIN t2 USING (col);

Te dwa identyczne zapytania łączą kolumnę t1.col z kolumną t2.col, ale także zwrócą niepołączone rzędy w t1 (te, które nie pasują w t2). RIGHT join dodałby niepołączone rzędy z tabeli t2. FULL join zwróciłby rzędy plus dodatkowo wszystkie rzędy z tabel t1 i t2. Słowo OUTER jest opcjonalne i jest dodawane domyślnie przy LEFT, RIGHT, i FULL join'ach. Zwykłe join'y są nazywane INNER joins.

W poprzednich wersjach "outer joins" mogą być zasymulowane poprzez użycie slowa kluczowego UNION i NOT IN. Dla przykładu, łącząc tabele tab1 i tab2, następujące zapytanie wykonuje outer join:

        SELECT tab1.col1, tab2.col2
        FROM tab1, tab2
        WHERE tab1.col1 = tab2.col1
        UNION ALL
        SELECT tab1.col1, NULL
        FROM tab1
        WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
        ORDER BY col1

#### 4.24) Jak wykonywać zapytanie używające kilku baz danych jednocześnie?

Nie ma takiej możliwości aby w zapytaniu odpytawać inną baze danych poza bieżącą. Ponieważ PostgreSQL ładuje specyficzne dla bazy danych katalogi systemowe, nie jest do końca jasne jak zapytanie pomiędzy różnymi bazami danych powinno się zachowywać.

contrib/dblink pozwala na wykonywanie zapytań poprzez różne bazy danych wywołując odpowiednie funkcje. Oczywiście klient może łączyć się z różnymi bazami danych i łączyć informację w ten sposób uzyskaną po stronie klienta.

#### 4.25) Jak zwrócić w funkcji wiele rzędów lub kolumn?

Możesz w łatwy sposób zwracać wiele rzędów lub kolumn używając funkcji z: http://techdocs.postgresql.org/guides/SetReturningFunctions.

#### 4.26) Dlaczego nie mogę w sposób pewny tworzyć/usuwać tabel tymczasowych w funkcjach PL/PgSQL?

PL/PgSQL przechowuje w cache zawartość funkcji, niepożądanym efektem tego jest to, że gdy taka funkcja korzysta z tabel tymczasowych, które są później kasowane i odtwarzane, a funkcja wywoływana jest ponownie,jej wywołanie nie powiedzie się ponieważ cachowana funkcja wciąż będzie wskazywać na stara tablicę tymczasową. Rozwiązaniem tego problemu jest używanie EXECUTE aby korzystać z tabel tymczasowych w PL/PgSQL. To spowoduje, że zapytanie będzie parsowane przy każdym wywołaniu funkcji.

#### 4.27) Jakie są możliwości replikacji w PostgreSQL?

Jest kilka opcji aby stosować replikację typu master/slave. Ten typ pozwala jedynie masterowi na dokonywanie zmian w bazie danych, a slave może jedynie te zmiany odczytywać. Na stronie http://gborg.PostgreSQL.org/genpage?replication_research znajduje się ich lista. Replikacja typu multi-master jest w trakcie prac, opis projektu znajduje się pod adresem: http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.

#### 4.28) Jakie możliwości szyfrowania oferuje PostgreSQL?

- contrib/pgcrypto zawiera wiele funkcji za pomocą, których możemy używać kryptografii w zapytaniach SQL.
- Aby szyfrować transmisję od klienta do serwera, ten musi mieć ustawioną opcję ssl na true w pliku postgresql.conf, odpowiedni wpis host lub hostssl musi występować w pliku pg_hba.conf, oraz sslmode nie może być wyłączone w kliencie. (Warto zwrócić uwagę, że możliwe jest także używanie transportów szyfrująców przez strony trzecie, takie jak stunnel lub ssh, poza natywnym wsparciem dla SSL przez PostgreSQL).
- Hasła użytkowników bazy danych są automatycznie szyfrowane od wersji 7.3. W poprzednich wersjach, należy tą funkcjonalność poprzez włączenie opcji PASSWORD_ENCRYPTION w postgresql.conf.
- Serwer może działać używając szyfrowanego systemu plików.

## Rozwijanie PostgreSQL

#### 5.1) Napisałem własną funkcję. Kiedy użyję jej w psql, program zrzuca pamięć (dump core)?

Problem może być spowodowany przez bardzo wiele rzeczy. Spróbuj najpierw przetestować Twoją funkcję w samodzielnie działającym programie.

#### 5.2) Jak mogę dodać/zgłosić nowe typy czy funkcje do PostgreSQL?

Wyślij Twoje propozycje na listę mailową pgsql-hackers, wtedy prawdopodobnie Twój kod znajdzie się w katalogu contrib/.

#### 5.3) Jak napisać funkcję C zwracającą krotkę (tuple)?

W wersjach PostgreSQL od numeru 7.3, funckje zwracające tabele są w pęlni wspierane w C, PL/PgSQL i SQL. Sprawdź w Programmer's Guide aby uzyskać więcej informacji. Przykład funkcji napisanej w C zwracającej tabelę został umieszczony w contrib/tablefunc.

#### 5.4) Zmieniłem plik źródłowy. Dlaczego po rekompilacji nie widać zmiany?

Pliki Makefiles nie mają dorzuconych odpowiednich zależności dla plików nagłówkowych (include files). Wykonaj najpierw make clean, a następnie ponownie make. Jeśli używasz GCC możesz użyć opcji --enable-depend przy wykonywaniu configure aby kompilator mógł określić zależności samodzielnie.