Alexey Nalbat <nalbat@price.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?
regards, tom lane
