| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 28. 리그렛션테스트 | Fast Forward | Next |
적절하게 설치되어, 모든 기능을 사용할 수 있는 것 같은 PostgreSQL 설치여도, 다양한 부동 소수점의 표현이나 메세지와 같은, 어느 플랫폼 특유의 오차를 때문에 리스레션 테스트를 "실패"하는 일이 있습니다. 현재의 테스트는 단순하게, 레퍼런스 시스템에서 생성한 출력과 diff를 비교하여 결과를 검증하고 있기 때문에, 사소한 시스템의 차이에도 반응합니다. 결과가 "실패"로 나타나면, 항상 예측했던 결과와 실제 결과의 차이를 살펴보아 주세요. 그러한 차이가 중대하지 않는 것으로 판명되기도 합니다. 뿐만 아니라, 모든 테스트가 성공하도록, 지원하는 모든 플랫폼에 대한 정확한 참조 파일의 보수에 노력하고 있습니다.
실제의 리그렛션테스트의 출력물은 src/test/regress/results디렉토리내의 파일에 있습니다. 테스트 스크립트는 diff를 사용해, 각 출력 파일과 src/test/regress/expected디렉토리내의 참조용 출력을 비교합니다. 모든 차이는 검사을 위해 src/test/regress/regression.diffs에 보존됩니다 (혹은, 스스로 diff를 실행할 수도 있습니다).
어떠한 이유로, 특정의 플랫폼이 지정한 테스트가 "실패"했을 때, 그 출력의 검사 결과가 유효하다고 확신할 경우, 새로운 비교용 파일을 추가해, 향후의 테스트에서 실패 보고가 발생하지 않게 할 수가 있습니다. 자세한 것은 Section 28.3을 참조해 주세요.
리그렛션테스트의 몇 개는 고의로 무효인 입력값을 사용합니다. 에러 메세지는 PostgreSQL의 코드나 사용하고 있는 플랫폼의 함수에 의하는 것이 있습니다. 후자의 경우, 플랫폼에 의해 차이가 있을지도 모릅니다만, 비슷한 내용일 것입니다. 이러한 메세지의 차이에 의해 리그렛션테스트가 "실패"할 가능성이 있습니다만, 이것들은 테스트로 확인할 수 있습니다.
이미 설치된 C로케일 이외의 조합순서 로케일로 초기화된 서버에 대해서 테스트를 실행하려면 , 정렬순서나 폴로 업의 실패에 의해 차이가 생길 가능성이 있습니다. 리그렛션테스트스위트는 이 문제를 해결하기 위해서, 많은 로케일을 처리하기 위한 대체 결과 파일을 제공하도록 설정되어 있습니다.
대부분의 일자와 시간의 결과는 시간대의 환경에 의존합니다. 참조 결과의 파일은 PST8PDT시간대(캘리포니아주 버크 레이)를 기준에 생성되고 있습니다. 따라서, 테스트가 이 시간대에 실행되지 않으면 분명히 실패로 끝날 것입니다. 리그렛션테스트의 드라이버는 결과가 바르게 되도록, PGTZ환경 변수를 PST8PDT로 설정합니다.
64 비트(double precision형)의 부동 소수점수(실수)치를 테이블의 열로부터 꺼내 계산하는 테스트가 있습니다. double precision열에 있어서의 수학 연산 함수에서는, 다른 결과가 발생하는 경우가 있습니다. float8와 geometry테스트는 특히, 플랫폼 간 또는 컴파일러의 최적화 옵션에 의한 작은 차이가 일어나기 쉽습니다. 이러한 차이가 중요한지 아니면 무시할 수 있는지는, 사람의 눈으로 실제로 확인할 필요가 있습니다. 통상적으로는 소수점 이하 10 자리수째가 될 것입니다.
시스템에 따라 마이너스 0을 -0이라고 표시하며, 0만으로도 표시하기도 합니다.
시스템에 따라서 현재의 PostgreSQL의 코드가 상정하는 메커니즘과 다르기 때문에,
pow()와 exp()의 에러를 발생하기도 합니다.
같은 행의 출력이 예상된 파일의 순서와 다른 경우가 있습니다. 대부분의 경우, 이것은 엄밀하게 말해 버그가 아닙니다. 대부분의 리그렛션테스트는 각 SELECT문에 대해서 ORDER BY를 사용하는 규칙이 어렵지 않고, 그 때문에, 결과의 행의 순서는 SQL의 사양에 따라 명확하게 정해져 있지 않습니다. 실제로는, 같은 소프트웨어로 같은 데이터를 같은 쿼리로 참조하고 있으므로 모든 플랫폼에서 같은 순서의 결과가 나오기 때문에, ORDER BY가 없는 것이 문제는 아니라고 말할 수 있습니다. 그러나, 쿼리에 따라서는, 플랫폼 간의 순서의 차이가 일어날 가능성이 있습니다. 설치가 끝난 서버에 대해서 테스트를 실시하는 경우, C 이외의 로케일, 그리고 독자적인 work_mem나 독자적인 플래너의 비용 매개변수 등과 같은 기본값 이외의 매개변수 설정에 의해 순서의 차이가 생길 가능성이 있습니다.
따라서, 순서의 차이가 일어났을 때, 쿼리에 ORDER BY가 포함되어 있어 순서에 영향을 미치는 경우 이외에는 신경쓰지 말아 주세요. 그러나, 특정의 쿼리에 ORDER BY를 추가해, 향후 릴리스에 거짓 "실패"를 없애기 위해서 보고해주세요.
리그렛션테스트의 쿼리에 순서 관련의 명령을 삽입하지 않는 것은, 필요가 없는 쿼리에 대해서도 쿼리 계획형을 실행하려고 하는 것 등과 같은 리그렛션테스트의 의의를 반대로 반감시키는 이유 때문입니다.
errors가 select infinite_recurse()명령으로 서버를 크래쉬 시켰을 경우, 플랫폼의 프로세스 스택 사이즈가 max_stack_depth 매개변수가 가리키는 값보다 작은 것을 의미합니다. 이것은, 스택 사이즈 제한을 높게 해 서버를 실행하는 것으로 수정할 수 있습니다(max_stack_depth의 기본값의 추천값은 4 메가바이트). 이것을 실시할 수가 없는 경우, max_stack_depth의 값을 줄이는 것이 대안입니다.
random테스트 스크립트는, 무작위 결과를 생성하는 것을 목적으로 하고 있습니다. 랜덤 리그렛션테스트는 드물게 실패로 끝납니다. 다음과 같이,
diff results/random.out expected/random.out
라고 입력하면, 단지 몇 줄의 차이가 생길 것입니다. 반복적으로 실패하지 않는 한, 신경 쓸 필요는 없습니다.