Oracle/MySQL/PostgreSQLにおけるサブクエリを含むDMLの非互換性 - SH2の日記

JPOUG Advent Calendar 2013の23日目です。比較的簡単なDMLでもRDBMS間の非互換性が出てしまうという怖い話をします。 +----+------+ | id | data | +----+------+ | 1 | a | | 2 | b | | 3 | c | +----+------+BEGIN; -- IDが最も小さいレコードをロックする SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE; (何らかの処理) -- 処理が終わったので削除する DELETE FROM q WHERE id = (1つ目のSQLで取得したID); COMMIT;IDが最も小さいレコードをロックし、何らかの処理を行って、最後にそのレコードを削除します。IDが最も小さいレコードを取得するというの

[sh2]

PostgreSQL Advent Calendarにもエントリすればよかった / id:nakunaru 一部のバージョンに不具合があるそうです http://jonathanlewis.wordpress.com/2011/03/20/upgrade-whoa/

[tmatsuu]

ふむ。この例の場合はサブクエリにもFOR UPDATEを入れるとMySQLのREAD COMMITTEDでもid=2が取れた。手元のMySQLは5.1.62だけど。

[indication]

採番テーブルが採用されやすくなりそう(たぶん別の理由)

[nakunaru]

あれ？11gR1だと挙動が違う？

[kazuyadesse]

( ´ ▽ ` )ﾉ

[lizy]

SERIALIZABLEならFOR UPDATEいらない？と思ったけどSELECT結果がかぶるか。最初にUPDATE+MINでそのトランザクションが処理するレコードを確保するのがいいのかも？