죄송합니다. 

제가 지난 번 글을 그냥 너무 쉽게 읽었네요, 

oid overflow 문제가 아니라, 트랜잭션 id overflow 문제였네요. 

이것은 commit 되지 않은, commit 되어도 checkpoint 작업이 정리가 덜 된 자료들이 한 테이블 안에 너무 많이 있으면 생기는 문제이기도 하고, 

빈번한 update, delete 작업이 있었는데, vacuum 작업이 일어나지 않아서 발생하는 문제이기도 합니다. 

autovacuum 작업 관련 로그를 남겨서, 해당 테이블의 vacuum 작업에 문제가 없는지 살펴보는 것이 첫번째 일인것같네요. 

문제가 있다면, 어디서 문제가 생겼는지 - 일반적으로 너무 잦은 dml 작업으로 vacuum 작업이 계속 지연 되어서 발생합니다. - 살펴보고 그 문제를 피해가거나(수동 vacuum) 다른 해결방법을 찾아야겠죠.

vacuum full 작업은 디스크 공간이 부족해서 최악의 상황일때 하는 작업입니다. 

디스크 공간이 넉넉하다면, 그냥 vacuum 만으로 충분합니다. 

일반적인 pg_start_backup을 이용한 데이터클러스터 백업은 

베이스백업가 아카이브 백업을 분리해서 생각하는데, 

대부분의 기업에서는 일주일에 한번 정도 베이스백업을, 매일또는 매시간 아카이브백업을 진행합니다. 

잦은 아카이브백업을 하면 백업량을 줄이는 효과가 있겠지만, 복구도 그 아카이브 조각 파일들을 다 반영해야하는 시간이 걸리겠죠. 

이런 저런 것들을 감안해서 최적의 백업정책은 해당 시스템에 맞게 스스로 찾으셔야할 것 같습니다.