pgsql에서 트렌젝션을 사용하지 않은 상태라는 것이 사실상 존재하지 않습니다. 모든 질의는 트렌젝션(multi version control)이 처리됩니다. 다만 auto commit이냐 아니냐의 문제일 뿐이죠.

결국 insert, update, delete가 동시에 실행될 경우 어떤 명령어가 먼저 실행되느냐에 따라서 그에 따른 lock이 걸리고 다른 명령어가 처리되지 않고 이전 명령어가 끝날 때까지 기다려야 할 경우가 생깁니다.

그리고 serial은 최대값까지 간 이후에 다시 첨부터 시작합니다. 결국 이전에 저장되어 있던 자료의 Id 값과 충돌 될 수 있는거죠. 하지만 bigserial형을 쓰면 bigint 형이니 만큼 그런일이 생길 가능성은 무척 작다고 생각됩니다.

다만 bigserial형을 쓸 때는 주의해야 할 것이 type cast를 해줘야 한다는 겁니다. type cast를 안해주면 index를 타지 않습니다.

8.0부터는 type cast를 안해줘도 되니 다행입니다.

길게 썼었는데, 제 컴이 오류를 내는 바람에. :(

많은 자료 변경이 이루워진다고 해도, 자료구조가 전체적인 자료 상태를 손상할 수 없는 자료구조라면 전혀 문제가 없겠지요. 하지만, 그 반대의 경우라면, 반드시 트랜잭션이 필요하고, 트랜잭션만으로도 안되면 테이블 잠금까지도 필요한 경우도 있습니다.

첫번째 예, 로그 기록 작업 처럼 계속해서 단순히 insert 만 하는 경우 - 이런거야, 기본키로 serial 형으로만 지정해 준다면, 별 문제 없이 insert, update, delete 에 아무런 문제 없이 진행될 것 같네요.

두번째 예, 주문서 작업 처럼, 주문자, 배송정보같은 주문정보와 주문내역으로 분리된 마스터-디테일 형태의 자료구조에서 insert 작업을 할 때, 마스터부터 insert 할 경우 - 이 경우는 작업방식을 주문번호를 먼저 구하고 그 주문번호로 주문내역(디테일)부터 작성하고, 맨 끝에 주문정보(마스터)를 입력하는 방식으로 바꾼다면, 굳이 트랜잭션으로 묶을 이유는 없겠지만, 아무튼 원칙대로 움직이려면, 반드시 트랜잭션 작업으로 처리되어야합니다.

세번째 예, 이 경우는 통장의 입출금 부분입니다. 현잔액을 먼저 구해야하고, 이때 테이블은 반드시 잠겨야합니다. 그리고 모든 작업이 끝날때까지 그 잠금은 지속되어야합니다.

지금까지 경험으로는 이런 예가 가장 적절한 것 같네요.

다음, 시퀀스 번호가 넘치면, 서버의 오류메시지가 시퀀스 번호가 넘쳐나서 작업이 취소 되었다고 하면서 작업을 중지합니다. 그 사이 관리자가 이 사실을 모르고 있다면, 조취를 취하기 전까지 계속해서 데이터는 손실되겠지요.

핫... sequence가 순환하지 않나요? 음.. 또 메뉴얼 100번 읽지 않은데서 오는 내공 부족을...

oid랑 제가 헛갈렸나 봅니다.

요즘은 너무 바빠서 경전(메뉴얼)을 자주 못 읽습니다. -.-;;

시퀀스에 no cycle 이라는 옵션이 있죵..

no cycle이 설정되면 순환하지 않습니다~

그리고 경쟁적으로 insert, update, delete가 일어날 때 "insert -> insert 된 데이터를 토대로 update -> update 된 데이터를 토대로 delete" 이런 종류의 작업이 아니라면 그냥 하셔도 될테구요. 한개의 세션에 종속된 작업들이 서로 데이터의 연관성이 있어야 한다면 필히 트랜젝션을 써야겠죵?