| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 14. 설치 지시(instruction) | Fast Forward | Next |
설정(Configuration)
installation 순서의 최초 단계는, 시스템에 맞추어 소스 트리를 설정해 사용하는 옵션을 선택하는 것입니다. configure 스크립트를 실행하는 것으로 끝납니다. 디폴트의 installation을 실시하는 경우는, 이하를 입력해 주세요.
. /configure
이 스크립트는, 각종의 시스템에 의존한 변수의 값을 추정하기 위해서 많은 시험을 실시해, 사용중의 운영시스템이 가지는 버릇을 검출해, 최종적으로 구축용 트리에 결과를 기록하기 위한 몇개의 파일을 작성합니다 (구축용의 디렉토리를 다른 곳으로 하고 싶은 경우는, 소스 트리의 밖의 디렉토리에서 configure를 실행할 수도 있습니다).
디폴트의 구성에서는, 서버, 유틸리티 외에, C컴파일러만을 필요로 하는 클라이언트 어플리케이션이나 인터페이스를 구축합니다. 디폴트에서는, 모든 파일은 /usr/local/pgsql이하에 installation 됩니다.
configure에 이하의 커맨드라인 옵션을 1개이상 지정하는 것으로, 구축 처리나 installation 처리를 변경할 수 있습니다.
/usr/local/pgsql 대신에, PREFIX 디렉토리 이하에 모든 파일을 installation 합니다. 파일은 실제로는 여러가지 서브 디렉토리에 installation 되어 PREFIX 디렉토리의 직접적으로 installation 되는 파일은 없습니다.
특별히 필요하다면, 이하의 옵션을 사용해 개개의 서브 디렉토리를 변경할 수도 있습니다. 그러나, 이것들을 그대로 사용했을 경우, installation는 위치 재변경이 가능해 집니다. 즉, installation의 뒤에 디렉토리를 이동할 수 있습니다 (man와doc의 장소는 이 영향을 받지 않습니다).
installation의 위치재변경을 위해서 ,configure의--disable-rpath를 사용하려고 생각할지도 모릅니다. 그 경우는, 운영시스템에 그 공유 라이브러리의 장소를 통지할 필요가 있겠지요.
아키텍쳐 의존의 파일을 PREFIX 의 설정과는 다른 접두사 EXEC-PREFIX 이하에 installation 할 수 있습니다. 호스트 사이에서 아키텍쳐-비의존의 파일을 공유하는 경우에 편리합니다. 생략 했을 경우, EXEC-PREFIX 는 PREFIX 와 같게 설정되어 아키텍쳐에 의존하는 파일도 비의존인 파일도 같은 트리 이하에 installation 됩니다.
실행 가능 프로그램용의 디렉토리를 지정합니다. 디폴트에서는 EXEC-PREFIX /bin이며, 통상적으로 /usr/local/pgsql/bin가 됩니다.
설치 된 프로그램으로 사용되는, 독해 전용 데이터 파일의 디렉토리를 지정합니다. 디폴트는 PREFIX /share입니다. 이것은 데이터베이스 파일을 저장하는 장소와는 전혀 관계가 없는 것에 주의해 주세요.
각종 설정 파일용의 디렉토리입니다. 디폴트에서는 PREFIX /etc입니다.
라이브러리나 동적 로드 가능 모듈을 installation 하는 장소입니다. 디폴트는 EXEC-PREFIX /lib입니다.
C 및 C++의 헤더 파일을 installation 하는 디렉토리입니다. 디폴트는 PREFIX /include입니다.
PostgreSQL 부속의 메뉴얼 페이지가 이 디렉토리 이하의, 대응 하는man x 서브 디렉토리에 설치됩니다. 디폴트는 PREFIX /man입니다.
"man"페이지 이외의 문서 파일이 이 디렉토리에 설치됩니다. 디폴트는 PREFIX /doc입니다. --without-docdir옵션이 지정되었을 경우, 문서는make install에 의해 설치되지 않습니다. 이것은, 문서의 설치용으로 특별한 방법을 가지는 패키지 작성 스크립트를 목적으로 하고 있습니다.
Note: (/usr/local/include라고 하는) 공용의 installation 장소에, 시스템의 다른 이름 공간에 영향을 주는 일 없이PostgreSQL를 설치할 수 있게 됩니다. 우선, 완전하게 전개한 디렉토리명에 "postgres"나"pgsql"라고 하는 캐릭터 라인이 포함되지 않은 경우,"/postgresql"라고 하는 캐릭터 라인이 자동적으로datadir,sysconfdir,docdir에 추가됩니다. 예를 들면, 접두사로서/usr/local을 사용하는 경우, 문서는/usr/local/doc/postgresql에 설치됩니다만, 접두사가/opt/postgres의 경우는/opt/postgres/doc에 설치 됩니다. 클라이언트 인터페이스용의 외부용 C헤더 파일은includedir에 설치되어 이름 공간의 문제는 없습니다. 내부전용 헤더 파일이나 서버용 헤더 파일은,includedir이하의 비공개 디렉토리에 설치됩니다. 각 인터페이스용의 헤더 파일을 꺼내는 방법에 대한 정보는, 그 인터페이스의 문서를 참조해 주세요. 마지막으로 동적 로드 가능 모듈용으로 libdir 이하에도 비공개용의 서브 디렉토리가 작성됩니다.
DIRECTORIES 에는, 컴파일러가 헤더 파일을 검색하는 디렉토리의 목록을 구두점으로 단락지어 지정합니다. (GNU Readline등의) 옵션의 패키지가 비표준적인 장소에 설치되고 있는 경우, 이 옵션과 대응하는--with-libraries옵션을 사용할 필요가 있습니다.
예： --with-includes=/opt/gnu/include:/usr/sup/include
DIRECTORIES 에는, 라이브러리를 검색하는 디렉토리의 목록을 구두점으로 단락지어 지정합니다. 패키지가 비표준적인 장소에 설치되고 있는 경우는, 아마 이 옵션(과 대응하는--with-includes옵션)을 사용할 필요가 있습니다.
예： --with-libraries=/opt/gnu/lib:/usr/sup/lib
각국어 서포트(NLS), 즉, 영어 이외의 언어에 의한 프로그램 메세지의 표시 기능을 유효하게 합니다. LANGUAGES 에는 서포트 예정 언어인 코드의 리스트를 공백에서 단락지어 지정합니다. 예를 들면,--enable-nls='de fr'등으로 합니다 (지정한 리스트와 실제로 준비된 번역과의 교점이 자동적으로 계산됩니다). 리스트에 아무것도 지정하지 않았던 경우, 이용 가능한 번역들 모두가 설치됩니다.
이 옵션을 사용하기 위해서는,gettext API의 실행이 필요합니다. 상기를 참조해 주세요.
서버와 클라이언트의 디폴트의 포트 번호를 NUMBER 로 설정합니다. 디폴트는 5432입니다. 이 포트는 다음에 언제라도 변경할 수 있습니다만, 여기서 지정했을 경우, 서버와 클라이언트는 컴파일시에 같은 디폴트치를 가지게 됩니다. 이것은 매우 편리합니다. 일반적으로 디폴트 이외의 값을 선택해야 할 유일한 이유는, 같은 머신 상의 복수의 PostgreSQL 서버를 가동시키는 것입니다.
PL/Perl서버 사이드 언어를 구축합니다.
PL/Python서버 사이드 언어를 구축합니다.
PL/Tcl서버 사이드 언어를 구축합니다.
Tcl는, Tcl에의 인터페이스 모듈을 구축하기 위해서 필요한 설정 정보를 포함한 파일tclConfig.sh를 설치합니다. 이 파일은 통상, 자동적으로 일반적으로 알려져 있는 장소에 설치됩니다만, 만약 Tcl의 다른 버젼을 사용하고 싶은 경우는, 설치하고 싶은 디렉토리를 지정할 수 있습니다.
Kerberos 5 인증의 서포트를 구축합니다. 많은 시스템에서는, Kerberos 시스템은 디폴트의 검색 장소(예를 들면/usr/include나/usr/lib)에 설치되고 있지 않습니다. 그 때문에,--with-includes와--with-libraries옵션을 더 추가해 사용해야 합니다. configure는, 처리를 진행시키기 전에 Kerberos가 올바르고 설치되고 있는 것을 확인하기 위해 필요한 헤더 파일과 라이브러리를 검사합니다.
Kerberos 의 서비스 법칙의 디폴트의 이름입니다). 디폴트에서는 "postgres"입니다. Windows 환경이 없는 한 변경할 이유는 특별히 없습니다.
SSL(암호화) 접속의 서포트를 유효하게 해 구축합니다. 이것에는,OpenSSL패키지가 설치되어 있어야 합니다. configure는, 처리를 진행시키기 전에OpenSSL의 설치를 확인하기 위해서, 필요한 헤더 파일과 라이브러리를 검사합니다.
인증 및 접속 파라미터 검색용의 LDAP 서포트를 유효하게 해 구축합니다. (Section 29.15및Section 20.2.5을 참조해 주세요. ) Unix에서는,OpenLDAP패키지가 설치되어야 합니다. configure는, 처리를 진행시키기 전에OpenLDAP의 installation이 충분히 되고 있는지 어떤지를 확인하기 위해서, 필요한 헤더 파일과 라이브러리를 검사합니다. Windows에서는 디폴트의 WinLDAP라이브러리가 사용됩니다.
Readline라이브러리( 및libedit)의 사용을 방지합니다. 이것에 의해 psql에서의 커맨드 라인 편집 및 이력이 무효가 되기 때문에, 추천 하지 않습니다.
GPL 라이센스의Readline 대신, BSD 라이센스의libedit라이브러리를 우선해 사용합니다. 이 옵션은 양쪽 모두의 라이브러리가 설치되고 있는 경우에게만 중요합니다. 이 경우 디폴트로Readline가 사용됩니다.
Bonjour 서포트를 유효하게 해 구축합니다. 이것에는 운영시스템이 Bonjour를 서포트하고 있는 것이 필요합니다. Mac OS X에서는 추천 합니다.
일자 시각 및 시간 간격으로, 디폴트의 부동 소수점 저장 방식 대신, 64 비트 정수 저장 방식을 사용합니다. 이것에 의해 표현할 수 있는 값의 범위가 좁아집니다만, 범위 전체에 대해서 마이크로 세컨드 단위의 정밀도를 보증할 수 있습니다. (자세한 것은 Section 8.5)(을)를 참조해 주세요. 디폴트의 부동 소수점 저장 방식 대신, 64 비트 정수 저장 방식을 사용함으로써 시시때때로 버그를 찾아낼 수 있습니다.
PostgreSQL가 그 플랫폼용의 CPU spin lock를 서포트하지 않는 경우에서도, 구축에 성공하도록 합니다. spin lock의 서포트의 결핍에 의해, 성능은 악화됩니다. 따라서, 이 옵션은 구축이 실패했을 때 그 원인이 사용하는 플랫폼에서 spin lock 서포트가 결핍 하고 있는 경우에게만 사용해 주세요. 사용하는 플랫폼에 있어서의PostgreSQL의 구축에 이 옵션이 필요하게 되었을 경우는,PostgreSQL개발자에게 그 문제를 보고해 주세요.
클라이언트 라이브러리를 쓰레드 세이프로 작성합니다. 이것에 의해, libpq나 ECPG프로그램내의 동시 실행 thread는, 안전하게 그 고유의 접속 핸들을 제어할 수 있습니다. 이 옵션은, 운영시스템으로 적절한 쓰레드 처리가 서포트되고 있는 것이 필요합니다.
Zlib라이브러리의 사용을 억제합니다. 이것은, pg_dump와 pg_restore에 있어서의 압축 어카이브(archive)의 서포트를 무효로 합니다. 이 옵션은, 이 라이브러리를 이용할 수 없는 매우 소수의 시스템전용만의 것입니다.
모든 프로그램과 라이브러리를 디버그 심볼 첨부로 컴파일 합니다. 이것은 문제를 해석하기 위해서 디버거를 사용해 프로그램을 실행할 수 있는 것을 의미합니다. 이것은 설치하는 실행 형식 파일의 사이즈를 꽤 크게 하고 GCC 이외의 컴파일러에서는, 일반적으로 컴파일러에 의한 최적화를 하지 않게 되기 때문에 속도가 느려집니다. 그러나 디버그 심볼을 이용할 수 있다고 하는 것은, 발생한 문제에 대응할 때에 매우 편리합니다. 현재로서는 GCC 를 사용하고 있는 경우에게만, 가동용의 installation에 이 옵션을 사용하는 것을 추천 합니다. 그러나 개발 작업시나 베타판을 실행할 때는, 항상 이것을 유효하게 해야 합니다.
서버에 있어서의, 많은 "있을 수 없는"상태를 테스트하는assertion 체크를 유효하게 합니다. 코드 개발 목적에서는 매우 가치가 있지만, 이 테스트에 의해 서버는 상당히 느려집니다. 또, 이 테스트를 유효하게 하면 서버의 안정성을 향상시킨다고는 할 수 없습니다! assertion 체크는 중요도에 의해 분류되고 있지 않으므로, 비교적 해가 없는 것 같은 버그에서도 서버의 재기동을 해 버립니다. 가동용으로 이 옵션을 사용하는 것은 추천 되지 않습니다만, 개발 작업시나 베타판을 실행하는 경우는 이것을 유효하게 해야 합니다.
자동 의존관계(dependencies) 추적을 유효하게 합니다. 이 옵션을 사용하면, 헤더 파일이 변경되었을 경우에 영향을 받는 모든 객체파일이 재구축 되도록 makefile이 설정됩니다. 이것은 개발 작업시에는 유용합니다만, 단지 한 번 컴파일 해 설치하는 것 뿐이라면, 이것은 쓸데없는 오버헤드입니다. 현재로서 이 옵션은 GCC 를 사용하고 있는 경우에게만 동작합니다.
동적 추적 툴 DTrace의 서포트를 유효하게 해 컴파일 합니다. DTrace를 서포트하는 운영시스템는 현재 Solaris 뿐입니다.
dtrace프로그램을 지시하기 위해서 DTRACE환경 변수를 설정할 수 있습니다. dtrace는 통상, 검색 패스내에 존재하지 않을 가능성이 있는/usr/sbin이하에 설치되고 있기 때문에, 이 설정은 자주 필요하게 됩니다. 추가적인 dtrace 프로그램용의 커맨드 라인 옵션을 DTRACEFLAGS 환경 변수로 지정할 수 있습니다.
64 비트 바이너리로 DTrace를 서포트하려면 ,DTRACEFLAGS="-64"를 설정해 주세요. 예를 들면 GCC 컴파일러를 사용하는 경우는 이하와 같이 합니다.
. /configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
Sun의 컴파일러를 사용하는 경우는 이하와 같이 합니다.
. /configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
configure가 선택한 것과 다른 C컴파일러를 사용하고 싶은 경우에는, CC 환경 변수를 그 사용하고 싶은 프로그램으로 설정할 수 있습니다. 디폴트에서는, configure는 이용할 수 있다면 gcc를, 이용할 수 없으면 플랫폼의 디폴트(통상cc)를 선택합니다. 같이 디폴트의 컴파일러 플래그는 필요에 따라서 CFLAGS 변수로 다시 쓸 수도 있습니다.
다음과 같은 configure커맨드 라인에 환경 변수를 지정할 수 있습니다.
. /configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
이하는, 이 방식에서 설정 가능한 중요한 환경 변수의 목록입니다.
C컴파일러입니다.
C컴파일러에 건네주는 옵션입니다.
C프리프로세서입니다.
C프리프로세서에 건네주는 옵션입니다.
dtrace프로그램의 장소입니다.
dtrace프로그램에 건네주는 옵션입니다.
링커에 건네주는 옵션입니다.
공유 라이브러리용의 링커 옵션입니다.
다언어 서포트(NLS) 용의msgfmt프로그램입니다.
Perl interpreter의 풀 패스입니다. 이것은, PL/Perl 구축에 관한 의존성을 결정하기 위해서 사용됩니다.
Python interpreter의 풀 패스입니다. 이것은, PL/Python 구축에 관한 의존성을 결정하기 위해서 사용됩니다.
Tcl interpreter의 풀 패스입니다. 이것은, PL/Tcl 구축에 관한 의존성을 결정하기 위해서 사용됩니다.
Yacc 프로그램(Bison를 사용하는 경우는bison -y)입니다.
구축
구축 작업을 개시하려면 , 이하를 입력해 주세요.
gmake
(GNU make를 사용하는 것을 잊지 말아 주세요. ) 하드웨어에 의존하여 구축 작업에는 몇분 걸립니다. 마지막에 이하와 같은 행이 표시될 것입니다.
All of PostgreSQL is successfully made. Ready to install.
리그렛션테스트
설치하기 전에, 새롭게 구축한 서버를 테스트하고 싶은 경우, 이 시점에서 리그렛션테스트를 실행할 수 있습니다. 리그렛션테스트란, 사용하는 머신에 대해 PostgreSQL가, 개발자의 상정 대로에 동작하는 것을 검증하기 위한 테스트의 정리입니다. 다음과 같이 입력합니다.
gmake check
(이것은 root 로서는 동작하지 않습니다. 비특권 유저로서 실행해 주세요. ) Chapter 28에는 테스트 결과의 표시에 관한 자세한 정보가 있습니다. 같은 커맨드를 입력하는 것으로, 후에 언제라도 테스트를 반복할 수 있습니다.
파일의 installation
Note: 만약 기존의 시스템의 업그레이드를 하고 있어, 이전의 파일 위로부터 새로운 파일을 설치한다면, 상기에 Section 14.4으로 설명한 것처럼, 확실히 데이터를 백업하여, 처리 전에 이전의 서버를 슛다운 해 주세요.
PostgreSQL를 설치하려면 , 이하를 입력해 주세요.
gmake install
파일을 step 1로 지정된 디렉토리에 설치합니다. 그 곳에 기입하기 위한 적절한 권한을 가지고 있는 것을 확인해 주세요. 통상 이 단계는 root로 실시해야 합니다. 대신에 대상으로 하는 디렉토리를 미리 작성해, 적절히 권한을 조정하는 일도 가능합니다.
gmake install대신에 gmake install-strip를 사용하는 것으로, 설치시에 실행 가능 파일이나 라이브러리를 스트립(strip) 할 수 있습니다. 이것에 의해, 다소의 용량을 절약할 수 있습니다. 디버그를 서포트하도록 구축한 경우, 스트립 하는 것으로 디버그의 서포트도 제거됩니다. 따라서, 이것은 디버그가 필요없게 되었을 경우에게만 실행해야 합니다. install-strip는 용량을 절약하기 위함이지만, 실행 가능 파일로부터 모든 불필요한 바이트를 완전하게 스트립 할 수 없습니다. 가능한 한의 디스크 용량을 모두 절약하고 싶다면 수동으로 작업을 해야 합니다.
이 표준설치방법에서는, 클라이언트 어플리케이션의 개발에 필요한 헤더 파일과 C로 독자적인 함수나 데이터형을 작성하는 서버측의 프로그램의 개발용의 헤더 파일이 준비됩니다 (PostgreSQL 8.0 전까지에서는, 다음에 별도 gmake install-all-headers커맨드가 필요했습니다. 그러나, 이 순서는 표준설치에 포함되었습니다).
클라이언트측만의 설치：. 클라이언트 어플리케이션과 인터페이스 라이브러리만을 설치하고 싶은 경우, 아래와 같은 커맨드를 사용합니다.
gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install
src/bin에는 서버용의 몇 개의 바이너리가 있지만 이것들은 작습니다.
Windows에 있어서의eventlog의 등록：. Windows eventlog라이브러리를 운영시스템에 등록하려면 , 설치후에 이하의 커맨드를 실행해 주세요.
regsvr32 pgsql_library_directory /pgevent.dll
이것에 의해 이벤트 뷰어로 사용되는 레지스트리 항목이 생성됩니다.
설치취소：. 설치를 취소하려면 ,gmake uninstall 커맨드를 사용합니다. 그러나 작성 끝난 디렉토리는 삭제되지 않습니다.
클리닝：. 설치가 끝나면,gmake clean 커맨드를 사용해 소스 트리로부터 구축용의 파일을 삭제해, 디스크의 영역을 비울 수 있습니다. 이것은 configure프로그램이 만드는 파일을 보관 유지하므로, 다음에 gmake 커맨드로 모두를 재구축 할 수 있습니다. 소스 트리가 배포되었을 때로 되돌리고 싶은 경우는, gmake distclean 커맨드를 사용합니다. 같은 소스 트리내에서 복수의 플랫폼전용으로 구축하는 경우, 반드시 이것을 하고 각각 재설정 되어야 합니다. (또는, 변경되지 않은 소스 트리를 유지하기 위해서 각 플랫폼에서 다른 구축용 트리를 사용해 주세요).
구축 작업을 실시한 다음에configure용 옵션이 잘못되어 있는 것을 깨닫았을 경우나,configure의 조사 결과에 어떠한 변경을 더했을 경우(예를 들면, 소프트웨어의 업그레이드 등), 재설정과 재구축의 전에gmake distclean를 실시하는 것을 추천합니다. 그렇지 않으면 설정 선택사항의 변경은 필요한 곳 모두에는 반영되지 않을 가능성이 있습니다.