PostgreSQL 버그 리포팅 가이드 라인

PostgreSQL 버그 리포팅 가이드 라인

 

● 오픈소스 프로젝트의 장점과 단점은 명확하다.

– 오라클이나 MSSQL 같이 비싼 라이센스 비용을 지불하지 않아도 상업적으로 이용이 가능하다.

– 단점은 국내에 오픈소스의 프로젝트들의 유지보수 업체나 전문가가 많지 않아 장애처리가 어렵다.

기술자가 있어도 몸값이 비싸다는것이 문제다.

● 어떤 프로그램이든 완벽한 동작을 하는 프로그램은 없다. 그렇기에 지속적인 버전업과 패치가 이루어 지는것.

 

버그 식별

● 프로그램이 fatal 신호와 함꼐 중단 또는 프로그램에 문제가 있음을 알리는 운영체제 메시지

● 주어진 입력에 대해 잘못된 출력이 프로그램에서 나옴

● 프로그램이 유효한 입력을 받아들이지 않음

● 프로그램이 경고 또는 에러 메시지 없이 잘못된 입력을 받아들임.

● 지원 플랫폼에 대한 지치에 따른 PostgreSQL의 컴파일, 빌드 또는 설치 실패

※ 느려지는 것이나, 리소스 호깅이 반드시 버그인 것은 아니다.

어플리케이션 튜닝에 대한 도움은 관련 문서를 보거나 메일링 리스트에 문의.

 

리포트 내용

● 문제의 재현을 위해 필요한 프로그램 시작부터 정확한 순서의 단계. SQL 관련 문제를 테스트할 때 최선의 형식은 문제를 보여주는 psql 프론트엔드를 통해 실행 가능한 파일이다. 이 파일을 간단하게 만드는 방법은 pg_dump를 사용하요 덤프하고 문제 쿼리를 추가하는 것.

● 에러메세지의 제시. 단순히 개인적인 의견으로 작동안함, 충돌함. 이런 의견은 아무런 도움이 되지 않는다. 에러메세지의 내용이 이해되지 않더라도 반드시 첨부한다.

 

로그 세팅

psql에서 \set VERBOSITY verbose

서버 로그에서 메세지 추출 하는 경우 log_error_verbose를 verbose로 설정

● 예상된 출력은 서술이 매우 중요하다. 두리뭉실한 표현은 커맨드의 정확한 의미를 해독하는데 시간을 소비할 수 있다. 단순히 “오라클에서는 되는 문장인데 PostgreSQL에서는 안된다.” 라고 기술하는 것도 옳지 않다. 모든 다른 데이터베이스의 동작은 자신만의 방식으로 동작하며, 데이터베이스 전문가라고 해서 모든 DB의 동작 방식을 알고 있는 것이 아니다.

● 기본값에서 변경된 관련 환경 변수 또는 구성 파일을 비롯한 커맨드 라인 옵션 및 기타 시작 옵션의 정확한 정보를 제공하기 바란다.

● 설치 지침과 다르게 실행한 모든것

● PostpgeSQL 버전. SELECT version();을 실행하면 연결된 서버의 버전을 알 수 있다. 최소한 postgres –version, psql –version은 지원한다. 해당 함수 또는 옵션이 존재하지 않는 경우 업그레이드를 해야할 만큼 오래된 버전이다.

● 플랫폼 정보, 커널 이름과 버전, C라이브러리, 프로세서, 메모리 정보 등이 포함.

 

버그 리포트를 보낼 곳

pgsql-bugs@postgresql.org

또는 프로젝트 웹사이트에서 버그 리포트 웹 양식에 입력.

● 버그 리포트에 보안에 관련된 사항이 있어 공용 아카이브에 공개되지 않기를 원한다면,

security@postgresql.org

개인적으로 리포트 할 수 있음.

● 프로젝트가 제공하는 문서에 문제가 있을 경우

pgsql-doc@postgresql.org

● 개발 제안, 플랫폼 이식 등 문제는 개발자의 메일링 리스트로 보낸다.

pgsql-hackers@posgresql.org

※ 당연히 영어로 적어서 보내야 한다.

 

참고 할 수 있는 사이트

프로젝트 홈페이지

https://www.postgresql.org/

PostgreSQL 한국 홈페이지

http://postgresql.kr/

데이터베이스사랑.net

http://database.sarang.net