데이터베이스 서버 로그를 /dev/null 쪽으로 보내서 그냥 버리기 보다 그것을 어떤 장소에 보관하는 것이 좋다. 왜냐하면 장애 원인 분석을 할 때 서버 로그는 중요한 단서가 되기 때문이다. 하지만, 원인 분석을 위해서 서버 로그를 보다 자세히 남기도록 설정을 했거나, 서버가 바빠서 로그가 많이 쌓이는 경우, 그 로그 파일이 분석하기 힘들 정도로 크기가 커져버리는 경우도 발생한다. 이러 이유로 서버 로그 파일에 대한 주기적인 관리 작업도 필요하다. 대표적인 작업이 로그를 크기나, 날짜 단위로 쪼개서 로그 파일의 크기를 분석하기 편하도록 하는 일과 아주 오래된 로그 파일들을 지워 로그 파일이 쌓이는 디렉터리의 여유 공간을 일정하게 유지 하도록 하는 일 등이다.

서버 로그를 파일로 저장하는 가장 간단한 방법은 postgres의 stderr 출력을 파일로 저장하는 것이다. 하지만, 이렇게 로그 파일을 만들면, 로그 파일을 바꾸려고 할 경우, 서버를 중지 하거나 재실행 해야한다. 이런 운영 방식은 개발 환경에서는 받아드릴 수 있지만, 운영 환경 에서는 수용하기 힘들다.

stderr 출력을 파일로 저장 할 때는 그 내용을 특정 로그 파일로 쉽게 바꾸어 저장할 수 있는 프로그램을 사용한다. 이 방법 말고, 서버 내부적으로 이런 로그 파일을 바꾸는 기능을 이용하는 방법도 있다. 이 기능을 사용하려면, postgresql.conf에서 logging_collector 환경 설정값을 true로 지정하고, 서버를 재실행 한다. 이 기능의 작동 방식을 제어하는 환경 설정 매개 변수들이 몇가지 있는데, 이들에 대한 자세한 설명은 19.8.1절에서 한다. 또한, 서버 로그를 컴퓨터가 쉽게 분석할 수 있도록, CSV(반점 구분 양식, comma-separated values) 형태로 로그를 저장 할 수도 있다.

앞에서 잠깐 언급한 stderr 출력을 그대로 사용해서, 로그 파일를 쉽게 바꾸는 방법 가운데 하나는 Apache 배포판에서 제공하는 rotatelogs 프로그램을 파이프를 통해 사용하는 것이다. pg_ctl 명령으로 서버를 기동한다면, 이 프로그램은 모든 stderr 출력을 stdout 쪽으로 보내기 때문에, 단순하게 다음과 같은 명령으로 사용할 수 있다:

pg_ctl start | rotatelogs /var/log/pgsql_log 86400

You can combine these approaches by setting up logrotate to collect log files produced by PostgreSQL built-in logging collector. In this case, the logging collector defines the names and location of the log files, while logrotate periodically archives these files. When initiating log rotation, logrotate must ensure that the application sends further output to the new file. This is commonly done with a postrotate script that sends a SIGHUP signal to the application, which then reopens the log file. In PostgreSQL, you can run pg_ctl with the logrotate option instead. When the server receives this command, the server either switches to a new log file or reopens the existing file, depending on the logging configuration (see 19.8.1절).

로그 파일을 다루는 또 다른 한가지 방법은, 그 출력을 syslog 쪽으로 보내는 것이다. 이렇게 하면, syslog 프로그램이 로그 파일 관리에 대한 부분을 모두 담당한다. 이렇게 설정하려면, postgresql.conf 파일에서 log_destination 환경 설정 값을 syslog로 지정한다. syslog 프로세스에 SIGHUP 시그널을 보내서 로그 파일을 바꿀 수 있을 것이다. 물론 syslog 프로세스가 다루는 여느 로그 파일과 같이 logrotate 을 이용해서 그 파일을 특정 기준으로 바꿀 수도 있다.

하지만, 많은 시스템에서 이 방법은 잘 사용되지 않는다. 왜냐하면, syslog 특성상 기록해야할 내용이 너무 많으면 그 내용을 자르거나, 시스템이 너무 바쁘면 로그 기록을 간혹 안하기 때문이다. 또한 Linux 환경에서는 기본적으로 로그 내용 하나를 파일에 기록 할 때마다 OS의 디스크 I/O 버퍼에 있는 내용을 디스크와 동기화 하기 때문에, 성능 저하를 초래한다. (syslog 환경 설정 파일에 지정하는 로그 파일 이름 앞에 “-” 문자를 더 적어주면 이런 디스크 동기화 작업을 생략할 있다.)

로그 파일을 관리하는 작업 가운데 또 하나 고려 해야할 사항은 아주 오래된 로그 파일 처리에 대한 정책을 세우는 일이다. 일반적으로 일정 기간이 지난 로그 파일은 주기적으로 삭제하는 정책을 만든다. 그리고 그 작업을 자동화 하는 방식을 택한다. 또 다른 방법은 로그 파일 이름을 순환 하는 형태로 정하고, 해당 로그를 해당 파일에 기록하는 방식을 사용해서, 로그 파일 개수가 일정하게 유지 되도록 한다.

아울러 이 로그 파일을 사용하는 몇몇 도구를 소개하면, pgBadger 라는 서버가 남긴 로그 파일을 정교하게 분석해서 보여주는 외부 프로젝트가 있다. check_postgres 스크립트는 Nagios 경고 모듈로 사용할 수 있다. 이것으로 로그 파일에 기록 된 내용들 가운데, 경고가 필요한 내용을 정교하게 지정해서 찾을 수도 있다.