[pgsql-jp: 32148] Re: トランザクション中に ERRORが発生するとABORT する
TANIDA Yutaka
tanida @ sra.co.jp
2004年 1月 28日 (水) 13:56:18 JST
谷田です。
On Wed, 28 Jan 2004 13:19:27 +0900
"Ebihara, Yuichiro" <Yuichiro.Ebihara @ jp.sony.com> wrote:
> 指定されて仕方なくOutlook2002を使ってますが、このままでは申し訳ない
> ので、このメールを出したら回避方法が分かるまでしばらく発言を控えよ
> うと思います。このメールだけどうかご容赦下さい。
どうしようもないのであれば、別にそのままでもいいのではないかと思います。
> さて本題ですが、私はnested transactionのことは考慮していません。
(snip)
> それからSAVEPOINTそのものは私にとって問題の本質ではないです。
(snip)
> 「SQL文のエラー、即トランザクションのロールバック」がDBMSにとって
> あるべき仕様なのでは? という見解に対し、疑問を感じる理由の1つとして
> 例に挙げたまでです。
>
> Oracleだと(たぶんDB2も)SQL文のエラー発生後もトランザクションを継続
> することができます。エラーの原因となった文による変更のみがロールバッ
> クされます(文レベルのロールバック)。>
> その後トランザクションレベルのロールバックを行うか否かは、プログラマ
> の判断次第です。もちろんflat transactionの話です。
どんな形であれ部分的なロールバックが可能であれば、それはもはやflat
transactionではありません。
# 単に明示的にbegin , commitを1段階しか使わないからflat、というのは
# 違うのではないかと。
(snip)
> このような実装が採用されている理由などあれば是非とも知りたいところ
> です。
理由は、と聞かれたら「save pointやnested transactionに当たる機能がまだ実
装されて無いから」という事になると思います。なんとなれば、文レベルのロー
ルバックというのは「文を実行して、エラーが出たら文の実行直前まで自動的に
戻る。ただし大本のトランザクションは継続している」ということに他ならない
からです。
部分的なロールバックは、WALのundo(PostgreSQLでは実装されていない)を使う
事で実現可能らしいのですが、なぜWAL undoが出来てないのかという経緯は私も
よく知りません。
# この件は井上さんが詳しいはずです。
>
> --
> 海老原 雄一郎 / EBIHARA Yuichiro
> E-mail: Yuichiro.Ebihara @ jp.sony.com
>
--
TANIDA Yutaka <tanida @ sra.co.jp>
pgsql-jp メーリングリストの案内