저 쿼리가 작동 된다면 그게 오히려 버그 아닌가요?

당연히 작동 되지 않아야 하는 쿼리 아닌가 생각됩니다.

저런 쿼리가 작동되는 DBMS도 있나요?

---------

홋... ORACLE은 되는군요... -.-;;

ISOLATION LEVEL 때문인가요?

좌우간 되는군요.. 음냐...

----------

ISOLATIN LEVEL과는 상관 없겠군요. 저는 여태 DB 쓰면서 당연히 이런 것이 안될 것이라고 생각했는데... 되는군요.

-------------

ㅎㅎㅎ sybase도 되는 군요. 그렇다면 MS SQL도 당연히 되겠네요.

MSSQL 도

+ , - 왔다갔다 잘되는군요

확실한 버그네요.

mydb=> create table test( a int not null primary key );
알림:  CREATE TABLE / PRIMARY KEY 명령으로 "test_pkey" 인덱스를 "test" 테이블에 자동으로 만들었음
CREATE TABLE
mydb=> commit;
COMMIT
mydb=> insert into test values(1);
INSERT 356588 1
mydb=> insert into test values(2);
INSERT 356589 1
mydb=> update test set a=(a+1);
오류:  중복된 키값이 "test_pkey" 유니크 제약조건을 위반했습니다
mydb=> rollback;
ROLLBACK
mydb=> insert into test values(2);
INSERT 356590 1
mydb=> insert into test values(1);
INSERT 356591 1
mydb=> update test set a=(a+1);
UPDATE 2

정책상의 문제도 아닌 것 같고, 능력이 안되서 미쳐 이문제를 못 풀었거나, 아니면, 놓쳤던가. 둘 중 하나인 것 같습니다. 일단 보고를 해야겠네요. 

관련된 논의가 예전에 있었군요.

http://groups.google.co.kr/group/mailing.database.pgsql-bugs/browse_thread/thread/1aff178dddbf8c9c/c24d583c1a883efe?lnk=st&rnum=1&hl=ko#c24d583c1a883efe

http://groups.google.co.kr/group/comp.databases.postgresql.hackers/browse_thread/thread/8b254b67487d3a71/e69e8c10524909ca?lnk=st&rnum=3&hl=ko#e69e8c10524909ca

결론은... 이 문제는 pgsql의 버그가 맞구요. 이미 잘 알려진 사실인 것 같습니다.

Jan은 이것을 처리하려면 시스템에 너무 무리가서 메모리 부족으로 죽을 수도 있을 것이기 때문에 하지 않는 것이 좋다는 생각이고 Vadim은 선택권은 사용자에게 있다는 말이네요.

dirty read를 구현해야 한다는데 그 이유는 모르겠습니다. 다만 pgsql의 특성상 내부적으로는 dirty read가 가능하고 다만 이것을 외부에 노출시키기만 하면 된다는 군요.

그런데... 앞으로 하자... 정도에서 끝난 것 같습니다. 이 이후에 어떻게 논의가 진행됐는지 궁금하네요.