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)

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