From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexey Nalbat <nalbat(at)price(dot)ru>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] deadlock with truncate and foreing keys |
Date: | 2008-02-18 21:37:08 |
Message-ID: | 20080218132513.D7895@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Mon, 18 Feb 2008, Tom Lane wrote:
> Alexey Nalbat <nalbat(at)price(dot)ru> writes:
> > create table t1 ( id integer primary key, name text );
> > create table t2 ( id integer references t1 );
> > insert into t1 values ( 1 );
> > insert into t2 values ( 1 );
>
> > Then two concurrent transactions start.
>
> > /* 1 */ begin;
> > /* 1 */ truncate t2;
> > /* 2 */ begin;
> > /* 2 */ update t1 set name='foo' where id=1;
> > /* 1 */ insert into t2 values ( 1 );
>
> > Here we have deadlock.
>
> Hmm, this happens because RI_FKey_keyequal_upd_pk does
>
> fk_rel = heap_open(riinfo.fk_relid, AccessShareLock);
>
> but right offhand I see no reason for it to do so --- it doesn't
> *do* anything with fk_rel except close it again. Likewise
> RI_FKey_keyequal_upd_fk doesn't seem to really need to touch the
> pk_rel. Is there something I'm missing in that? Maybe this is
> a vestige of earlier coding that did need to touch both rels
> to perform the keysequal check?
Probably something like that - maybe ri_BuildQueryKeyFull might have
needed it open. Actually, I'm wondering if the ri_BuildQueryKeyFull call
is also unnecessary now - I don't think we ever use the qkey that comes
out of it unless I'm missing some code.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-02-18 21:58:04 | Re: [HACKERS] deadlock with truncate and foreing keys |
Previous Message | Alvaro Herrera | 2008-02-18 21:35:11 | Re: Pains in upgrading to 8.3 |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-02-18 21:45:39 | Re: Ad Hoc Indexes |
Previous Message | Tom Lane | 2008-02-18 21:28:25 | Re: Ad Hoc Indexes |