해당 자료의 자료형 목록을 구하는 쿼리가 오동작을 했다는 소리인데,

그 원인이, 하나만 리턴해야할 자료인데, 여러개가 리턴되었기 때문이라네요.

이 오류는 유추해 볼 수 있는 것이

시스템 카타로그 정보가 이상한 경우 일 것 같네요.

일단 pg_dump 사용할 때, -v 옵션을 추가해서, 어느 테이블에서 저런 오류가 나는지 확인해보고,

그 해당 테이블의 시스템 카타로그 정보를 차근히 살펴보는 것이 해결책일 듯싶습니다.

이 참에, pg_ 테이들도 한번 공부해보세요. 자료구조를 배우는데 많은 도움을 받을 수 있을겝니다.

(골치 아프면, 서버 버전과 같은 pg_dump 프로그램을 사용하고, 사용하기 전에, vacuum full 명령으로 자료정리를 한번 하고 다시 시도해보세요.)

우선 답변에 감사드립니다.

두가지 질문이 더 있는데요.

1.Vacuum full 명령을 해보았는데요.

dbtest=# vacuum full;
ERROR:  Index tbboard_5_file_pkey is not a btree

와 같은 식의 에러가 발생됩니다.

btree 라는 것이 뭔말인지.. 여기 DSN 을 검색해봐도 위와 같은 에러로 질문이 올라온것 이 없어서 여쭈어 봅니다.

2.데이터베이스 이름을 바꿀수 있는 방법이 있나요?

alter database 로는 이름을 바꾸는 방법이 없는 것 같습니다.

pg_database 의 바꾸려는 DB 명을 Update 로 바꾸면 되는 것인지..

지금 서비스중인 것이 있어서 pg_database 는 건드리지 않았습니다.

vacuum full 의 저경우가 바로 reindex 명령이 필요한 경우입니다.

그 인덱스를 사용하는 테이블을 대상으로 reindex 명령을 사용해서 새로 만들어야할 경우같네요.

----

database rename 관련은 SQL 구문이 있습니다.

ALTER DATABASE name RENAME TO newname

이거 쓰면 될터인데요.

7.3.2 에서는 rename 이 지원되지 않는 것 같아서 질문드렸습니다.

\h alter database 를 해도

rename 에 관련된 사항은 없네요.

마찬가지로 alter database name rename to newname

도 적용이 안되네요..

죄송합니다..먼저 버전을 말했어야 하는데..

혹시 아시나요???

alter database oldname rename to newname

명령의 내부 루틴을 살펴보았는데요.

하는 일이,

일단 pg_database 테이블 잠그고,

바꾸려는 데이터베이스가 현재 세션의 데이터베이스인지 확인하고,

다른 사용자들이 현재 이 데이터베이스를 쓰는지 체크하고,

권한이 슈퍼유저 권한인지 체크하고,

다 적당하면, pg_database update 하고, 강제로 하드디스크에 저장하는 것으로 끝냅니다.

즉, 이 일을 수동으로 처리하려면,

가장 안전하게, 일단 모든 열려 있는 세션을 닫고 접속하지 못하도록 하고,

template1 db 로 접속해서,

update pg_database set datname = 'newdbname' where datname = 'olddbname';

명령을 실행하고,

db 서버를 restart 하는 것이 제일 안전한 방법일 듯합니다.

---------

그런데, 7.3.2 버전은 그 뒤로 많은 패치가 이루워진 버전입니다.

부득이 자료 덤프를 할 수 없는 상황이라면,

서버 패치버전만이라도 바꾸시길 바랍니다.

한국어 관련으로 치명적인 버그가 7.3.6에서 고쳐지고, 트랜잭션관련 치명적인 버그가 7.3.7 ... 등등 현재 그나마 안정적인 것이 7.3.9 버전이니, 이버전으로 바꾸어 사용하시길.