| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | 서론 | Fast Forward | Next |
PostgreSQL에 관해서 버그를 발견했을 경우, 꼭 알려 주세요. 최대한의 주위를 기울여도, 모든 환경에서의 모든 플랫폼에서 PostgreSQL의 기능 모두가 정상적으로 움직이는 것은 보증할 수 없기 때문에, 버그 리포트는 PostgreSQL의 신뢰성을 높이기 위해서 몹시 중요합니다.
아래와 같은 조언은, 버그 리포트가 효율적으로 활용되기 위한 것입니다. 이것에 따를 의무는 없습니다만, 다른 사람에게 유익한 것이 될 수 있습니다.
발견된 버그는 즉시 수정된다고는 할 수 없습니다. 그 버그가 명확하고 중대하여 다른 많은 사용자에게도 영향을 주는 경우, 곧바로 수정될 가능성이 높을 것입니다. 또, 보다 새로운 버젼으로 바꾼 후에도 같은 일이 일어나는지를 확인받도록 추천하는 경우도 있습니다. 혹은, 현재 계획 중인 큰 변경이 종료할 때까지 버그를 수정할 수 없다고 판단하는 경우도 있습니다. 또, 버그 수정이 매우 난이도가 높아 뒷전이 되는 경우도 생각할 수 있습니다. 시급하게 처치가 필요한 경우는, 상업적 지원 계약을 검토해 주세요.
버그 보고를 실시하기 전에, 문서를 읽고 또 다시 확인하여 실행하고자 하는 처리의 실행 가능여부를 확인해 주세요. 실행 가능 여부가 불명한 경우는, 그 취지를 보고해 주세요. 그것은 어느 의미 문서의 버그입니다. 또, 문서에 쓰여져 있는 것으로 실제의 결과가 다른 경우는 그것은 버그가 됩니다. 이하와 같은 상황이 생각됩니다. 그러나 이것들만으로 한정하고 있는 것은 아닙니다.
프로그램이 치명적인 시그널, 또는 operating system의 에러 메세지로 종료해, 그것이 프로그램의 문제를 가리키는 경우 (반대로, "disk full"와 같은 메세지는 프로그램의 문제가 아니기 때문에, 이 경우는 스스로 수정해 주세요).
프로그램이 입력된 값에 대해서 잘못한 결과를 돌려주는 경우.
유효한 값을 입력해도 프로그램으로 받아들이지 않는 경우(문서로 정의된 대로) .
무효인 값을 입력해, 에러 메세지등의 표시 없이 프로그램이 그 값을 받아들이는 경우. 그러나, 무효인 입력이라고 생각되고 있는 것이라도, 실제로는 확장이나 전통적인 이유에 의한 호환성을 때문에 유효로 하고 있을 가능성도 있기 때문에 주의해 주세요.
지원되고 있는 플랫폼에서, PostgreSQL가 순서 대로에 컴파일, 빌드, 설치톨 할 수 없는 경우.
여기에서는, "프로그램"는 백엔드 서버 만이 아니고, 모든 실행 가능한 프로그램을 의미합니다.
프로그램의 실행이 늦거나 자원을 대량으로 사용하는 것이 반드시 버그는 아닙니다. 어플리케이션을 개선하기 위해서는, 문서를 읽거나 메일링리스트를 확인해 주세요. 그 기능의 호환성을 명확하게 하지 않았다면, 표준SQL의 요구에 응하지 않는 것은 버그라고 말할 수 없습니다.
계속해서 진행하기 전에, 그 버그가 기존의 것인지 TODO 리스트나 FAQ에서 확인해 주세요. 만약 TODO 리스트로부터 정보를 읽어낼 수가 없으면, 문제를 보고해 주세요. 적어도 TODO 리스트를 명확하게 할 수가 있습니다.
버그 보고에서 가장 중요한 것은, 오직 사실만을 그리고 모든 사실을 명확하게 기술하는 것입니다. 무엇이 일어났는지 또는 프로그램의 어디가 문제인가에 대해서 '무엇 무엇이 일어나고 있는 것 같다'등의 억측이나 추측을 기술하지 말아 주세요. 실장에 그다지 익숙하지 않은 분의 추측은 올바르지 않은 경우가 있어, 유효한 버그 보고가 되지 않습니다. 실장에 정통하고 있는 분의 경우에도, 근거가 있는 설명은 참고 정보가 될 수 있지만, 역시 올바른 사실이 가장 도움이 됩니다. 버그를 수정하기 위해서는, 우선 개발자 자신이 그 버그를 재현 할 필요가 있습니다. 있는 그대로의 사실을 보고하는 것은 단도직입적(많은 경우 화면으로부터 메세지를 그대로 복사하기만 할 뿐)입니다만, 자칫하면, 중요하지 않을 것이라고, 혹은 생략해도 이해 할 수 있을 것이라고 간과하여 중요한 정보를 놓치게 되는 경우가 많이 있습니다.
모든 버그 보고에서는 아래와 같은 내용이 기술되어 있어야만 합니다.
문제를 재현 할 수 있도록, 프로그램의 기동으로부터 간 작업을 순서 대로에 기술해 주세요. 예를 들면, 결과가 테이블의 데이터에 의존한다면, SELECT문을 기술하고 있어도, 그 이전에 행해진 CREATE TABLE나 INSERT문이 기술되어 있지 않으면 충분하다고는 말할 수 없습니다. 사용자의 데이터베이스 스키마를 역공학하기 위한 시간이 없고, 데이터를 추측해 구축했다고 하더라도 아마 문제를 놓치게 될 것입니다.
SQL에 관련한 문제의 시험 케이스의 최적 버그 보고 방법은, 문제를 재현 할 수 있도록 psql프론트엔드에서 직접 읽어들이게 할 수 있는 파일을 준비하는 것입니다. (~/. psqlrc의 스타트업 파일에 아무것도 쓰여지지 않은 것을 확인해 주세요.) 이 파일을 간단하게 취득하려면, pg_dump를 사용해 테이블 정의와 그 상황을 재현 시키기 위해서 필요한 데이터를 뽑아내고 문제가 일어난 쿼리를 추가합니다. 데이터 예의 양을 줄이는 것은 추천 됩니다만, 반드시 필요하지는 않습니다. 어느 방법을 취하더라도 버그를 재현 할 수 있으면 좋습니다.
어플리케이션이 PHP등과 같은 다른 클라이언트 인터페이스를 사용하고 있는 경우, 문제가 되는 쿼리를 제거해 주세요. 문제를 재현 시키기 위해서, 아마도 Web 서버를 설정하는 것은 하지 않을 것입니다. 어떠한 경우에서도 정확한 입력 파일을 제공하는 것을 잊지 말아 주세요. "대규모 파일"이나 "중 규모 데이타베이스"에서 발생하는 문제 등이라고 추측은 하지 말아 주세요. 이러한 정보는 너무 부정확해 도움이 되지 않습니다.
얻은 결과 그 자체. "잘 되지 않았다"나 "크래쉬 했다"등의 보고는 하지 말아 주세요. 에러 메세지가 있다면, 의미를 이해할 수 없어도 그대로 보고해 주세요. operating system의 에러로 프로그램이 강제 종료해 버리면, 에러 그대로 보고해 주세요. 아무것도 일어나지 않는 경우도, 그 취지를 보고해 주세요. 비록 테스트 케이스의 결과가 프로그램의 크래쉬 등이 명확한 경우라도, 우리의 플랫폼에서 재현 할 수 없는 경우가 있습니다. 가장 용이한 방법은, 결과를 터미널로부터 카피하는 것입니다.
Note: 에러 메세지를 보고하는 경우, 그 메세지를 최대한 자세하게 확보해 주세요. psql라면 미리 \set VERBOSITY 해 를 지정해 주세요. 서버 로그로부터 메세지를 꺼내는 경우는, 모든 디테일을 로그 취득할 수 있도록 log_error_verbosity 실행시 파라미터를 verbose로 설정해 주세요.
Note: 치명적인 에러가 일어났을 경우, 클라이언트측에서 보고되는 에러 메세지에는 필요한 정보 모두가 쓰여져 있다고는 할 수 없습니다. 데이터 베이스 서버의 로그를 확인해 주세요. 만약 로그를 취하지 않다면, 취하는 습관을 붙여 주세요.
어떠한 결과를 기대하고 있었는지를 기술하는 일도 매우 중요합니다. 단지 "이 커멘드는 이러한 결과를 돌려주었다"나, "이러한 결과를 바라지 않았다"는 표현 만으로는, 재현 해 결과를 검증했을 때에 개발자에게는 올바른 결과일 가능성이 있습니다. 받은 명령의 배후에 있는 의미를 모두 파악할 수 없습니다. 또, 특히 특히"SQL에서는 이렇게 쓰여지지 않은"이나"Oracle에서는 이와 같이 안 되는" 과 같은 설명은 삼가해 주시기 바랍니다. SQL의 정확한 동작을 찾아내는 것은 즐거운 작업이 아니고, 또, 세상에 있는 다른 RDB의 동작 모두를 PostgreSQL의 개발자가 파악하고 있지 않습니다. (문제가 프로그램의 크래쉬인 경우, 이 내용은 말할 필요 없이 생략 할 수 있습니다).
명령 라인과 스타트업때의 모든 옵션과 기본값으로부터의 변경과 관련된 환경 변수나 설정 파일도 정확하게 기술해 주세요. 다시한번 말하지만, 정확한 정보를 제공해 주세요. OS의 부팅 시에 데이터 베이스 서버를 시작하도록 패키지 된 배포분을 사용하는 경우는, 그것들이 어떻게 실행되고 있는지를 확인할 필요가 있습니다.
설치지침으로부터의 변경점을 모두 기술해 주세요.
PostgreSQL의 버젼. SELECT version();로 접속되어 있는 서버의 버젼을 알 수 있습니다. 많은 실행 가능한 프로그램에서는 --version옵션도 사용할 수 있습니다. 적어도 postgres --version와 psql --version는 실행할 수 있을 것입니다. 이 함수나 옵션을 사용할 수 없는 경우는, 그 버젼은 매우 오래된 것이므로 업그레이드 해야 합니다. RPM등과 같은 사전에 패키지 된 것을 사용하고 있는 경우에 패키지의 부버젼이 만약 있으면 함께 기재해 주세요. CVS판에 대한 버그 보고시에는 그 취지와 일시를 기재해 주세요.
8.3.3보다 버젼이 오래된 경우, 업그레이드 하는 것을 추천합니다. 새로운 발매물에서 많은 버그 수정이나 개선이 이루어지고 있기 때문입니다. 그러므로, 오래된 PostgreSQL의 발매물을 사용하고 있어 불편사항이 이미 수정되고 있을 가능성이 꽤 있습니다. 오래된 PostgreSQL의 발매물을 사용하고 있는 현장에 대해서, 우리는 한정된 지원 밖에 제공할 수가 없습니다. 그 이상의 지원 필요하면, 상업적 지원 계약을 맺는 것을 검토해 주세요.
플랫폼 정보. 커넬명과 버젼, C라이브러리, 프로세서, 메모리 정보등도 포함해 보고해 주세요. 많은 경우, 공급업체명과 그 버젼을 명기하는 것만으로 충분합니다만, "Debian"의 정확한 원가요소를 모든 사람이 파악하고 있다든지, Pentium를 사용하고 있다는 생각은 삼가해 주세요. 설치에 관한 문제의 경우는 기계의 툴체인(컴파일러나 make등)의 정보도 필요합니다.
버그 보고가 장문이 되어도 어쩔 수 없는 것이므로, 신경쓰지 말아 주세요. 한 번에 모든 정보를 입수할 수 있다면, 개발자로부터 정보를 재촉 하는 수고와 시간이 걸리지 않습니다. 한편, 파일이 크다면, 그 정보에 누가 관심이 있을지를 먼저 묻는 것이 좋을 수 있습니다. 기사에 버그 보고에 대한 더 많은 요령들의 개요가 있습니다.
문제를 해결시키는 입력을 찾아내기 위한 시간을 소비하지 말아 주세요. 이것은 아마 문제 해결에 도움이 되지 않을 것입니다. 버그가 즉석에서 수정되지 않는 경우, 그 사이를 이용해 여러가지를 시험해 보세요. 다시 한번 말하면, 버그가 왜 있는지를 해명하는데 불필요한 시간이 들일 필요는 없습니다. 개발자가 충분히 빠른 시간 내에 찾아낼 것입니다.
버그 보고를 할 때, 이해하기 쉬운 용어를 사용해 주세요. 이 소프트웨어 패키지 전체는 "PostgreSQL"로 불리고 있습니다만, 생략해 "Postgres"라고도 불립니다. 특히 연구 백엔드 서버에 관해서는 그대로 명시하고, "PostgreSQL의 크래쉬"라고 기술하지 말아 주세요. 1개의 연구 백엔드 서버의 크래쉬와 그 parent process"postgres"의 크래쉬와는 꽤 다릅니다. 1개의 연구 백엔드 프로세스가 다운해 버린 것을 "서버의 크래쉬"라고 기술하지 말아 주세요. 그 역의 경우에도 들어맞읍니다. 또, "psql"과 같은 대화식 프론트엔드등의 클라이언트 프로그램은 연구 최종 단계와는 완전하게 분리되어 있습니다. 문제가 클라이언트측인지 아니면 서버측인지를 분리하도록 주세요.
일반적으로는, <pgsql-bugs@postgresql.org>라고 하는 버그 보고용 메일링리스트에 버그 보고서를 보내 주세요.
버그 보고서의 제목에는, 에러 메세지의 일부분과 같이 알기 쉬운 것을 사용해 주세요.
그 밖에, 프로젝트의 Web 사이트에 있는 버그 보고서 형식을 이용하는 방법이 있습니다.
이 방법으로 입력한 버그 보고는, <pgsql-bugs@postgresql.org>메일링리스트에 송신됩니다.
버그 보고에 보안과 관련하는 경우나 공개 아카이브(archive)로부터 곧바로 열람할 수 있는 것을 선호하지 않는 경우,
pgsql-bugs에 송신하지 말아 주세요.
보안 문제는 개별적으로 <security@postgresql.org>에 보고할 수가 있습니다.
<pgsql-sql@postgresql.org>나 <pgsql-general@postgresql.org>등의 사용자전용의 메일링리스트에는
절대 버그 보고를 보내지 말아 주세요.
이러한 메일링리스트는 사용자의 질문에 답하기 위한 것으로, 대부분의 구독자는 버그 보고를 받는 것을 원치 않을 것입니다.
더 중요한 점은, 이 구독자에 의해 버그가 수정되는 경우는 거의 없다는 것입니다.
또, 개발자전용의 <pgsql-hackers@postgresql.org>에도 버그 보고서를
보내지 말아
주세요.
여기는 PostgreSQL의 개발에 관해서 논의기 위한 리스트이며, 버그 보고서와는 분리하는 편이 좋습니다.
만약 그 문제에 의해 많은 리뷰가 필요한 경우는, 그 버그 보고를 pgsql-hackers로 논의하게 됩니다.
문서에 관해서 문제가 있는 경우는, 문서용 메일링리스트 <pgsql-docs@postgresql.org>에 보고하는 것이 가장 좋습니다.
그 때, 문서에서 문제가 된 부분이 어디인지 명시해 주세요.
또, 지원되어 있지 않은 플랫폼에의 이동성에 관련된 버그 보고인 경우는 <pgsql-ports@postgresql.org>에 보고해 주세요.
개발자들이 그 플랫폼에 PostgreSQL를 이식하기 위해 (보고자와 함께) 최선의 노력을 할 수 있습니다.
Note: 유감스럽게도, spam 메일을 방지하기 위해서 위의 메일링리스트는 비공개되고 있습니다. 즉, 이러한 메일링리스트에 투고하려면 강독해야합니다. (그러나, Web 폼에 의한 버그 보고서의 경우는 구독할 필요는 없습니다). 메일링리스트로부터의 메일을 받지 않고 단지 메일을 보내고 싶은 경우는, 구독 등록을 실시해, 강독 옵션을 nomail로 설정해 주세요. 상세한 정보에 대해서는 본문에 help을 써서
<majordomo@postgresql.org>에 메일을 보내주세요.