E.17.1. 버전 9.3.9로 마이그레이션

9.3.X를 실행하는 경우 덤프/복원이 필요하지 않습니다.

그러나 당신이 이전 설치를 업그레이드하는 경우 이전에 a를 사용하여 업그레이드했습니다.pg_upgrade버전 9.3.0과 9.3.4 사이 아래의 첫 번째 변경 로그 항목을 참조하세요.

또한 9.3.7 이전 버전에서 업그레이드하는 경우, 참조스포츠 토토 PostgreSQL : 문서 : 9.3 : 릴리스 9.3.7.

E.17.2. 변경사항

• 일관되지 않은 데이터베이스에서 복구할 수 없는 오류 수정 주(로버트 하스)

  최근포스트그레SQL출시 multixact 랩어라운드를 방지하기 위한 메커니즘을 도입했지만 해당 코드 중 일부는 다음과 같은 가능성을 고려하지 않았습니다. 데이터베이스가 없을 수 있는 경우 응급 복구 중에 실행해야 합니다. 일관된 상태. 이로 인해 일정 시간이 지난 후 다시 시작하지 못할 수 있습니다. 충돌 또는 보조 서버 시작 실패. 여운 이전에 수정된 버그의 영향pg_upgrade또한 이러한 실패를 일으킬 수 있습니다. 사용한 설치 수pg_upgrade9.3.0과 버전 사이 9.3.4.

  그pg_upgrade문제의 버그 설정될 거라고 했어.oldestMultiXid1로 에서pg_control참값이더라도 더 높아야합니다. 이번 릴리스에 도입된 수정 사항을 통해 다음과 같은 문제가 발생했습니다. 상황이 발생하면 즉시 긴급 자동 진공 처리가 수행됩니다. 맞습니다oldestMultiXid값은 다음과 같습니다. 결정됨. 이것이 어려움을 초래할 경우 사용자는 다음과 같이 이를 피할 수 있습니다. 수동으로 청소하는 중이전에이 릴리스로 업그레이드 중입니다. 에서 세부정보:

  1. 다음 여부 확인pg_controldata보고"최신 체크포인트 가장 오래된MultiXid"1이 되려면. 그렇지 않으면 할 일이 없습니다.

  2. 찾아보세요PGDATA/pg_multixact/오프셋에 이름이 파일인지 확인하세요.0000. 만약에 있어, 할 일이 없어.

  3. 그렇지 않으면 다음이 있는 각 테이블에 대해pg_class.relminmxid1과 같음,진공두 가지가 모두 포함된 테이블vacuum_multixact_freeze_min_age그리고vacuum_multixact_freeze_table_age0으로 설정되었습니다. (진공 비용 지연 매개변수를 사용할 수 있습니다. 설명됨섹션 18.4.4동시 성능에 미치는 영향을 줄이기 위해 세션.) 다음을 사용해야 합니다.포스트그레SQL9.3.5 이상에서 이 단계를 수행하세요.

• 관계 캐시 초기화 파일을 무효화하는 드문 오류 수정(Tom 레인)

  동시 활동의 타이밍이 잘못되어 a진공이 가득 참시스템 카탈로그의 업데이트가 실패할 수 있음"초기화 파일"그것은 피하는 데 사용됩니다 새 세션에 대한 캐시 로딩 작업. 이로 인해 나중에 세션이 해당 카탈로그에 전혀 액세스할 수 없습니다. 이것은 매우 고대 버그이지만 유발하기가 너무 어려워 재현 가능한 사례가 없습니다. 최근까지 목격되었습니다.

• 수신 세션 간의 교착 상태를 방지하고데이터베이스 생성/삭제(톰 레인)

  대상인 데이터베이스에서 시작되는 새 세션은데이터베이스 삭제명령이거나 템플릿입니다. 에 대한데이터베이스 생성명령, 원인이 될 수 있음 5초 동안 기다렸다가 실패하는 명령은 새 명령이 적용되더라도 그 전에 세션이 종료되었을 것입니다.

• 세미 조인 및 안티 조인에 대한 기획자의 비용 추정 개선 내부 인덱스 스캔 사용(Tom Lane, Tomas Vondra)

  이러한 유형의 계획은 모든 조인 절이 다음과 같을 때 상당히 저렴합니다. 내부 스캔이 수행되더라도 인덱스 스캔 조건으로 사용됩니다. 명목상 많은 행을 가져옵니다. 왜냐하면 실행 프로그램은 다음 후에 중지되기 때문입니다. 하나의 행을 얻습니다. 기획자는 부분적으로만 설명했습니다. 결과적으로 비용을 과대평가하게 되어 결과적으로 훨씬 덜 효율적인 다른 계획 유형을 선택할 수도 있습니다.