이 문제로 Postgres 메일링 리스트에 포스팅 해보았으나,

희망적인 대답이 나오지는 않더군요.

결국 닭질을 시작했습니다.

왜냐하면, 다섯명이서 거의 한달간 입력한 자료인데,

그것을 다시 그사람들에게 입력해 달라고 하기에는

너무도 가혹한 짓인 것 같아서 /./

문제의 테이블이 vacuum 되기 전이다는 것을 감안해서,

데이터가 변동되기 전에 제빨리, 테이블 파일을 복사를 해서,

오늘 하루 종일, 그 파일의 구조 분석에 들어갔고,

한 6시간 뒤즈음에 100% 복구를 했습니다.

덕분에, hexcode를 얼마나 많이 보았는지 모르겠습니다. /./

이 사태를 치르고 나니, 오직 생각 나는 것은

백업철저! 이것 뿐이더군요. /./

잡담: 개인적으로 기능적으로 공개용 RDBM 치고는 Postgres 만한것이

없어서 Postgres를 제일 많이 사용하는데, 이 사태를 격고 나니,

Oracle의 undo log가 무진장 부럽더군요. /./

정재익 님께서 쓰시길::

> 오옷.. 그런 엄청난 실수를...

> 안타깝게도 commit 이 마지막 보루입니다.

> 논리적으로 다시 살릴수는 없습니다.

> PostgreSQL의 경우 로깅 시스템이 아직 불완전하여 살릴수가 없습니다.

> 날아간 자료에 조의를... /./

> 필히 데이터는 백업을 받으시기 바랍니다. 현재로서는 그 방법 말고는 좋은 방안이 없는 것 같습니다.