버그 보고 지침

PostgreSQL 에서 버그를 발견하면 이에 대해 듣고 싶습니다. 최대한 주의를 기울이더라도 PostgreSQL 의 모든 부분이 모든 상황에서 모든 플랫폼에서 작동 한다고 보장할 수는 없기 때문에 버그 보고서는 PostgreSQL 을 보다 안정적 으로 만드는 데 중요한 역할을 합니다.

다음 제안은 효과적인 방식으로 처리할 수 있는 버그 보고서를 작성하는 데 도움을 주기 위한 것입니다. 아무도 따르지 않아도 되지만 그렇게 하면 모두에게 유리한 경향이 있습니다.

모든 버그를 즉시 수정하겠다고 약속할 수는 없습니다. 버그가 명백하거나 치명적이거나 많은 사용자에게 영향을 미치는 경우 누군가가 버그를 조사할 가능성이 높습니다. 버그가 발생하는지 확인하기 위해 최신 버전으로 업데이트하라는 메시지가 표시될 수도 있습니다. 또는 계획하고 있는 주요 재작성이 완료되기 전에 버그를 수정할 수 없다고 결정할 수도 있습니다. 아니면 너무 어렵고 의제에 더 중요한 일이 있을 수도 있습니다. 즉시 도움이 필요하면 상업적 지원 계약을 받는 것이 좋습니다.

5.1. 버그 식별

버그를 보고하기 전에 문서를 읽고 다시 읽고 시도하는 것이 무엇이든 실제로 할 수 있는지 확인하십시오. 문서에서 당신이 할 수 있는 일을 할 수 있는지 없는지 명확하지 않다면, 그것도 보고하십시오. 문서의 버그입니다. 프로그램이 문서에서 말하는 것과 다른 작업을 수행하는 것으로 판명되면 버그입니다. 여기에는 다음 상황이 포함될 수 있지만 이에 국한되지 않습니다.

• 프로그램은 프로그램의 문제를 가리키는 치명적인 신호나 운영 체제 오류 메시지와 함께 종료됩니다. (반례는 " 디스크 꽉 참 " 메시지일 수 있습니다. 이 메시지는 직접 수정해야 하기 때문입니다.)
• 프로그램은 주어진 입력에 대해 잘못된 출력을 생성합니다.
• 프로그램이 (문서에 정의된 대로) 유효한 입력 수락을 거부합니다.
• 프로그램은 통지나 오류 메시지 없이 잘못된 입력을 허용합니다. 그러나 잘못된 입력에 대한 귀하의 아이디어는 기존 관행과의 확장 또는 호환성에 대한 당사의 아이디어일 수 있음을 명심하십시오.
• PostgreSQL 은 지원되는 플랫폼의 지침에 따라 컴파일, 빌드 또는 설치에 실패합니다.

여기서 " 프로그램 " 은 백엔드 프로세스뿐만 아니라 모든 실행 파일을 나타냅니다.

느리거나 리소스를 많이 사용하는 것이 반드시 버그는 아닙니다. 문서를 읽거나 메일링 리스트 중 하나에서 애플리케이션 조정에 대한 도움을 요청하십시오. 특정 기능에 대한 준수가 명시적으로 주장되지 않는 한 SQL 표준 을 준수하지 않는 것이 반드시 버그는 아닙니다.

계속하기 전에 TODO 목록과 FAQ에서 버그가 이미 알려져 있는지 확인하십시오. TODO 목록의 정보를 해독할 수 없으면 문제를 보고하십시오. 우리가 할 수 있는 최소한의 일은 TODO 목록을 더 명확하게 만드는 것입니다.

5.2. 보고할 내용

버그 보고에 대해 기억해야 할 가장 중요한 것은 모든 사실과 사실만을 진술하는 것입니다. 무엇이 잘못되었다고 생각하는지, " 무엇 을 하는 것 같았 는지 " , 또는 프로그램의 어느 부분에 오류가 있는지 추측하지 마십시오. 구현에 익숙하지 않은 경우 잘못 추측하고 도움이 되지 않을 수 있습니다. 그리고 당신이 그렇다 할지라도, 교육받은 설명은 사실에 대한 훌륭한 보완책이지만 사실을 대체할 수는 없습니다. 버그를 수정하려면 먼저 버그가 발생하는지 확인해야 합니다. 단순한 사실을 보고하는 것은 비교적 간단하지만(화면에서 복사하여 붙여넣을 수 있음) 중요한 세부 사항이 중요하지 않거나 보고서가 어쨌든 이해될 것이라고 누군가 생각했기 때문에 너무 자주 중요한 세부 사항이 누락되었습니다.

모든 버그 보고서에는 다음 항목이 포함되어야 합니다.

• 문제를 재현하는 데 필요한 프로그램 시작부터 단계의 정확한 순서 . 이것은 독립적이어야 합니다. 출력이 테이블의 데이터에 의존해야 하는 경우 SELECT선행 CREATE TABLE및 문이 없는 베어 문으로 보내는 것만으로는 충분하지 않습니다 . INSERT데이터베이스 스키마를 리버스 엔지니어링할 시간이 없으며 자체 데이터를 구성해야 하는 경우 문제를 놓칠 수 있습니다.애플리케이션이 PHP 와 같은 다른 클라이언트 인터페이스를 사용하는 경우 문제가 되는 쿼리를 격리해 보십시오. 귀하의 문제를 재현하기 위해 웹 서버를 설정하지 않을 것입니다. 어떤 경우에도 정확한 입력 파일을 제공해야 합니다. " 대용량 파일 " 또는 " 중간 규모 데이터베이스 " 등에 문제가 발생한다고 추측하지 마십시오 . 이 정보는 사용하기에 너무 정확하지 않기 때문입니다 .
• SQL 관련 문제에 대한 테스트 케이스의 가장 좋은 형식은 문제를 보여주는 psql 프론트엔드를 통해 실행할 수 있는 파일입니다. (시작 파일에 아무 것도 넣지 마십시오 ~/.psqlrc.) 이 파일을 만드는 쉬운 방법은 pg_dump 를 사용 하여 장면을 설정하는 데 필요한 테이블 선언과 ​​데이터를 덤프한 다음 문제 쿼리를 추가하는 것입니다. 예제의 크기를 최소화하는 것이 좋지만 반드시 필요한 것은 아닙니다. 버그가 재현 가능한 경우 어느 쪽이든 찾을 수 있습니다.
• 당신이 얻은 출력. " 작동하지 않았다 " 또는 " 충돌 했다 "고 말하지 마십시오 . 오류 메시지가 있으면 이해하지 못하더라도 보여줍니다. 프로그램이 운영 체제 오류로 종료되는 경우 다음을 말하십시오. 아무 일도 일어나지 않으면 그렇게 말하십시오. 테스트 케이스의 결과가 프로그램 충돌이거나 명백하더라도 당사 플랫폼에서는 발생하지 않을 수 있습니다. 가장 쉬운 방법은 가능한 경우 터미널에서 출력을 복사하는 것입니다.

  메모

  치명적인 오류의 경우 클라이언트가 보고한 오류 메시지에 사용 가능한 모든 정보가 포함되어 있지 않을 수 있습니다. 데이터베이스 서버의 로그 출력도 살펴보십시오. 서버의 로그 출력을 유지하지 않는다면 지금부터 시작하는 것이 좋습니다.

• 메모
• 오류 메시지를 보고하는 경우 가장 자세한 형식의 메시지를 가져오십시오. psql 에서 미리 말 \set VERBOSITY verbose하십시오. 서버 로그에서 메시지를 추출하는 경우 모든 세부 정보가 기록되도록 런타임 매개변수 log_error_verbosity 를 로 설정합니다.verbose
• 예상한 출력은 매우 중요합니다. " 이 명령은 그 출력을 제공합니다. ” 또는 “ 이것은 내가 예상한 것이 아닙니다. " , 우리는 그것을 직접 실행하고 출력을 스캔하고 그것이 괜찮아 보이고 우리가 기대했던 것과 정확히 같다고 생각할 수 있습니다. 명령 뒤에 있는 정확한 의미를 해독하는 데 시간을 할애할 필요가 없습니다. 특히 “ 이것은 SQL이 말하는 바/오라클이 하는 것이 아닙니다. " SQL 에서 올바른 동작을 찾아내는 것은 재미있는 일이 아니며 우리 모두는 다른 모든 관계형 데이터베이스가 어떻게 동작하는지 알지 못합니다. (문제가 프로그램 충돌인 경우 이 항목을 분명히 생략할 수 있습니다.)
• 기본값에서 변경한 관련 환경 변수 또는 구성 파일을 포함한 모든 명령줄 옵션 및 기타 시작 옵션. 다시 한 번 정확한 정보를 제공해 주십시오. 부팅 시 데이터베이스 서버를 시작하는 사전 패키지 배포를 사용하는 경우 어떻게 수행되는지 알아보아야 합니다.
• 설치 지침과 전혀 다르게 수행한 모든 작업.
• PostgreSQL 버전 . 명령 SELECT version();을 실행하여 연결된 서버의 버전을 확인할 수 있습니다. 대부분의 실행 프로그램은 --version옵션도 지원합니다. 최소한 postgres --version작동 psql --version해야 합니다. 기능이나 옵션이 존재하지 않으면 버전이 업그레이드를 보증할 만큼 오래된 것입니다. RPM과 같은 사전 패키지 버전을 실행하는 경우 패키지에 있을 수 있는 모든 하위 버전을 포함하여 그렇게 말하십시오. Git 스냅샷에 대해 이야기하는 경우 커밋 해시를 포함하여 언급하십시오.
• 버전이 14.2보다 이전 버전인 경우 거의 확실하게 업그레이드하라는 메시지가 표시됩니다. 각각의 새 릴리스에는 많은 버그 수정 및 개선 사항이 있으므로 이전 PostgreSQL 릴리스에서 발생한 버그 가 이미 수정되었을 가능성이 큽니다. PostgreSQL 의 이전 릴리스를 사용하는 사이트에 대해서만 제한된 지원을 제공할 수 있습니다 . 우리가 제공할 수 있는 것보다 더 많은 것이 필요한 경우 상업적 지원 계약을 획득하는 것을 고려하십시오.
• 플랫폼 정보. 여기에는 커널 이름과 버전, C 라이브러리, 프로세서, 메모리 정보 등이 포함됩니다. 대부분의 경우 공급업체와 버전을 보고하는 것으로 충분하지만 " Debian " 이 정확히 무엇 을 포함하고 있는지 또는 모든 사람이 x86_64에서 실행되고 있는지 모든 사람이 알고 있다고 가정하지 마십시오. 설치 문제가 있는 경우 컴퓨터의 도구 체인에 대한 정보(컴파일러, make 등)도 필요합니다.

버그 보고서가 다소 길어져도 두려워하지 마십시오. 그것은 삶의 사실입니다. 우리가 당신에게서 사실을 짜내는 것보다 모든 것을 처음보고하는 것이 낫습니다. 반면에 입력 파일이 큰 경우 누군가가 파일을 조사하는 데 관심이 있는지 먼저 물어보는 것이 좋습니다. 다음은 버그 보고에 대한 몇 가지 추가 팁을 설명 하는 기사 입니다.

입력의 어떤 변경이 문제를 해결하는지 파악하는 데 모든 시간을 소비하지 마십시오. 이것은 아마도 해결에 도움이 되지 않을 것입니다. 버그를 즉시 수정할 수 없는 것으로 판명된 경우에도 해결 방법을 찾고 공유할 시간이 있습니다. 또한 다시 한 번 버그가 존재하는 이유를 추측하느라 시간을 낭비하지 마십시오. 우리는 곧 그것을 알게 될 것입니다.

버그 보고서를 작성할 때 혼동되는 용어를 사용하지 마십시오. 소프트웨어 패키지는 총칭하여 " PostgreSQL " , 줄여서 " Postgres " 라고도 합니다 . 백엔드 프로세스에 대해 구체적으로 이야기하는 경우 " PostgreSQL 크래시 " 라고만 말하지 마십시오 . 단일 백엔드 프로세스의 충돌은 상위 " postgres " 프로세스의 충돌과 상당히 다릅니다. 단일 백엔드 프로세스가 중단되었음을 의미할 때 " 서버 충돌 " 이라고 말하지 마십시오 . 그 반대의 경우도 마찬가지입니다. 또한 대화형 프론트엔드 " psql " 과 같은 클라이언트 프로그램백엔드와 완전히 분리되어 있습니다. 문제가 클라이언트 측인지 서버 측인지에 대해 구체적으로 시도하십시오.

5.3. 버그 보고 위치

일반적으로 버그 보고서를 의 버그 보고서 메일링 리스트로 보내십시오 . 오류 메시지의 일부인 전자 메일 메시지에 설명적인 제목을 사용하도록 요청받았습니다.<pgsql-bugs@lists.postgresql.org>

또 다른 방법은 프로젝트의 웹 사이트 에서 사용할 수 있는 버그 보고서 웹 양식을 작성하는 것 입니다. 이 방법으로 버그 보고서를 입력하면 메일링 리스트로 메일이 발송됩니다.<pgsql-bugs@lists.postgresql.org>

버그 보고서에 보안 관련 문제가 있고 공개 아카이브에 즉시 표시되지 않도록 하려면 로 보내지 마십시오 pgsql-bugs. 보안 문제는 에 비공개로 보고할 수 있습니다 .

또는 와 같은 사용자 메일링 리스트에 버그 보고서를 보내지 마십시오 . 이 메일링 리스트는 사용자 질문에 답하기 위한 것이며 일반적으로 구독자는 버그 보고서 수신을 원하지 않습니다. 더 중요한 것은 문제를 해결할 가능성이 없다는 것입니다.

또한 개발자의 메일링 리스트에 보고서를 보내지 마십시오 . 이 목록은 PostgreSQL 개발에 대해 논의하기 위한 것이며 버그 보고서를 별도로 보관할 수 있다면 좋을 것입니다. 문제에 대한 추가 검토가 필요한 경우 에 대한 버그 보고서에 대한 토론을 시작할 수 있습니다 .pgsql-hackers

문서에 문제가 있는 경우 보고할 수 있는 가장 좋은 곳은 문서 메일링 리스트 입니다. 문서의 어떤 부분이 불만족스러운지 구체적으로 말씀해 주십시오.

버그가 지원되지 않는 플랫폼의 이식성 문제인 경우 메일을 로 보내십시오 . 그러면 우리와 귀하가 PostgreSQL 을 귀하의 플랫폼으로 이식할 수 있습니다.

메모

유감스럽게도 스팸의 양이 많기 때문에 구독하지 않는 한 위의 모든 목록은 조정됩니다. 즉, 이메일이 전달되기까지 약간의 지연이 있습니다. 목록에 가입하려면 https://lists.postgresql.org/ 를 방문 하여 지침을 확인하십시오.