일단 DB server 에 에러가 발생했는데 이 내용만으로는 상황파악이 안되는군요. 해결 방법은 postgres 라는 DBA 계정으로 접속한 후에 psql db_name 한 다음 vacuum; 을 실행해 주세요. 대부분의 경우 해결됩니다.

2번 문제의 해결 법은 없는 것 같습니다. 현재로서는 catalog 파일에 대한 정보를 PostgreSQL 에서는 거의 제공하고 있지 않은 상황입니다. 그러므로 할수 없이 그냥 넘어가야 할 것 같습니다. /./

::이봉우 님께서 쓰시길::

> 여기서 도움만 받는 것 같아 죄송합니다. 저도 언젠가는 사람들에게 도움을 줄 수 있는 날이 오겠죠..

> !!!

>

> DB에 똑같은 문제가 이번주에만 두번째입니다. 첫번째는 그냥 복구했지만 이번에도 복구는 가능하지

> 만 이유를 알고 싶어 글을 올립니다. 예전에 모든 DB가 날아간 이후 메일메일 백업을 받는 것이 다행

> 이군요...

>

> 1. 우선 서버에 여러 개의 DB가 있고 DB 각각에는 여려개의 Table들이 있습니다.

> 문제가 겉으로 드러나 보이기엔 DB중 여러개의 Table 중에서 하나의 Table만 문제를 일으키고 있습니

> 다. 아래의 메시지는 board라는 DB에 boardn의 Table이 문제를 일으켰을 때 나타난 메시지를 옮겨 적은

> 것입니다.

>

> pg_dump /o board > board.out

> (board DB를 백업받기 위해 실행하는 명령, 아래의 메시지는 나타난 에러 메시지)

> pgWait() / connection not open.

> PQendcopy : resetting connection.

> SQL query to dump the contents of Table 'boardn' did not execute correctly. After we read all th

> e table contents from the backend, PQendcopy() failed.

> Explanation from backend:''

> The query was : 'COPY "boardn" WITH OIDS TO stdout;'

>

> 그래서 psql로 board DB에 연결한후 나타난 과정.

>

> board=> select * from boardn;

> Backend message type 0x44 arrived while idle.

> Backend message type 0x44 arrived while idle. (같은 두 줄의 메시지)

> We have lost the connection to the backend, so further processing is impossible. Terminating.

> 왜 이런 문제가 생기는 걸까요...?

>

> 2. 또, 하나 물어볼께요? PostgresSQL이 몇 달 돌고 나면 pg_log 파일의 사이즈가 굉장히 증가하는데

> 이 것을 깨끗히 clear 시키는 방법은 없나요..? 메뉴얼을 찾아보아도 이 부분의 내용은 잘 보이질 않

> 더군요..? 시험으로 그냥 지우고 파일을 같은 속성으로 새로이 생성시켰더니 DB의 모든 내용이 날아가

> 더군요...?

> 내용이 너무 길지만 답변 부탁드립니다.

>

> 이봉우 (levine91@nownuri.net)