Subject: [pgsql-jp 23955] Re: exited with status 139 From: Tatsuo Ishii To: pgsql-jp@sra.co.jp Date: Wed, 05 Dec 2001 22:51:59 +0900 Reply-To: pgsql-jp@sra.co.jp X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (葵) 石井です. > ・pg_exec_query_string に渡ってきている SQL 文に共通の特徴は、常に「update > 〜 set 〜 from 〜 where 〜」文 (from がある) で、set 内で field 自身の値に > field を代入していることです (x=x+1 のような形)。 > > ・デバッガで追った結果、 > postgresql-7.1.3/src/backend/executor/execQual.c:311 > > 310 case OUTER: /* get the tuple from the outer node > */ > 311 slot = econtext->ecxt_outertuple; > 312 break; > > ここの econtext->ecxt_outertuple が NULL で、 > > 323 heapTuple = slot->val; > 324 tuple_type = slot->ttc_tupleDescriptor; > > 323行目で落ちているらしい。 > > ・いつも落ちてしまう SQL 文も、常に落ちるわけではなくて、何らかのタイミン > グにはまった時に落ちるように見えます。 > > source をもっとしっかり追って原因を探る時間がなく、こちらでは結局、update > 文に from があると悪いのでは、と当たりをつけて、全ての update 〜 from 文を > 置き換えることで対処中です。 井上さんのフォローにあるように,7.2の開発中に発見されたバグが原因のよ うです.井上さんに私信で教えてもらった 7.2 用のパッチ(本家のコアメンバ が作成) が(そのコアメンバ自身が言うように多少 offset が出ますが),7.1 にも適用可能でした.よろしかったら,お試し下さい(で,症状が改善された かどうか教えて頂けると嬉しいです). ちなみに,コアメンバが作ったバグの再現データは,以下に示すように外部キー とRULEが使われている結構複雑なものです.加澤さんの場合は単純な update 〜 from でも落ちてしまうんですね. -- Tatsuo Ishii Subject: Re: [BUGS] Bug #514: Backend crashes periodically From: Tom Lane To: Warren Volz cc: pgsql-bugs@postgresql.org Date: Mon, 12 Nov 2001 00:58:51 -0500 Comments: In-reply-to Warren Volz message dated "Sun, 11 Nov 2001 23:20:20 -0500" Okay, I've extracted a reproducible test case from Warren's info: Setup: CREATE TABLE sis_user ( sis_user_id INTEGER PRIMARY KEY, last_visit DATETIME NOT NULL DEFAULT TEXT 'now'); CREATE TABLE session ( session_key CHAR(40) PRIMARY KEY, sis_user_id INTEGER NOT NULL REFERENCES sis_user(sis_user_id), last_access_time DATETIME NOT NULL DEFAULT TEXT 'now'); CREATE RULE session_del AS ON DELETE TO session DO UPDATE sis_user SET last_visit = OLD.last_access_time WHERE OLD.sis_user_id = sis_user.sis_user_id; insert into sis_user values(1); In session 1, do: insert into session values('zzz', 1); begin; delete from session where session_key = 'zzz'; In session 2, do: delete from session where session_key = 'zzz'; Back to session 1: end; Session 2 crashes. Crash happens in current sources as well as 7.1. The crash does NOT happen if the foreign key reference is removed from session.sis_user_id. I'm not sure at this point whether the rule is a crucial element or not. The problem appears to be generation of an invalid plan tree: the Var being decoded has varno = OUTER, which offhand I believe it should not have in an indexscan's qual tree. I'm tired and am going to bed soon, but perhaps someone else would like to poke at this before I get back to it... regards, tom lane