PostgreSQL : TRUNCATE 후 디스크 공간이 해제되지 않습니다

나는 TRUNCATE거대한 (~ 120Gb) 테이블을 만들었습니다 files.

TRUNCATE files;
VACUUM FULL files;

테이블 크기는 0이지만 디스크 공간이 해제되지 않았습니다. 잃어버린 디스크 공간을 되 찾는 방법에 대한 아이디어가 있습니까?

업데이트 : 디스크 공간은 ~ 12 시간 후에 아무런 조치도 취하지 않고 해제되었습니다. 우분투 8.04 서버를 사용합니다.

postgresql truncate disk-space

— 아담 마탄
소스

나는 "vacuum it!"을 제안하려고했지만 방금 제안한 것을 고려할 때 이것을 pg-hackers 또는 pg-performance list 중 하나로 가져가는 것이 좋습니다. 하나).

— Denis de Bernardy 2016 년

이 링크 ( postgresql.1045698.n5.nabble.com/… )에 대한 조언이 있습니까? 어쩌면 테이블이나 이와 유사한 것에 액세스하는 것이있을 수 있습니다.

— DrColossos 2016 년

@ DrColossos : PostgreSQL이 자르려고하는 모든 연결에 알리고 필요한 리소스를 잠근다 고 소스에서 주석 (지금은 찾을 수없는 주석)을 읽었습니다. (테이블 자체, 인덱스, 시퀀스 및 토스트 테이블을 포함하여 몇 가지가 있습니다.) ExecuteTruncate ()를 통해 추적하여 주석을 일찍 찾았지만 100 % 긍정적이지 않습니다.

— Mike Sherrill 'Cat Recall'6

에 따르면 소스에 주석 , truncate새, 빈 저장 파일을 생성하고, 커밋 시간에 오래 저장 파일을 삭제합니다. (문서에 따르면 "저장 파일"은 OS에 관한 한 파일 일 뿐이지 만 용어를 이해하지 못할 수도 있습니다.)

관계에 대해 비어있는 새 스토리지 파일을 작성하고 relfilenode 값으로 지정하십시오. 이전 스토리지 파일은 커밋시 삭제되도록 예약되어 있습니다.

파일을 삭제하는 것처럼 보이므로 기본 운영 체제에서 해당 공간을 즉시 확보하지 못할 수 있습니다. 예를 들어 스토리지 파일이 Windows의 경우 휴지통에있을 수 있습니다. 그러나 필자의 경우 PostgreSQL 9에서 테이블을 자르면 Windows의 여유 공간이 즉시 증가했습니다.

잘림도 WAL 로그에 기록됩니다. 그 효과가 얼마나 될지 모르겠습니다.

— 마이크 셰릴 '고양이 리콜'
소스

다른 백엔드 프로세스에는 여전히 파일 열기에 대한 파일 설명자가 있습니다. 이 문제가 다시 발생하면 다른 모든 백엔드 프로세스를 종료하여 차이가 있는지 확인합니다.

— Peter Eisentraut

ExecuteTruncate ()가 일어날 수 없다는 것을 읽었습니다. 이전 스토리지 파일을 결국 삭제하는 데 필요한 자원 잠금의 모든 부분. 그러나 나는 출처에서 어디서 그것을 찾았는지 모른다. 그냥 온라인으로 탐색하고 있습니다. 그렇게 길을 잃기 쉽습니다.

— Mike Sherrill 'Cat Recall'6