Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 18 Feb 2008, Tom Lane wrote:
>> 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
On Mon, 18 Feb 2008, Tom Lane wrote:
> Alexey Nalbat <[EMAIL PROTECTED]> 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 sta
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Alexey Nalbat" <[EMAIL PROTECTED]> writes:
>> create table t1 ( id integer primary key, name text );
>> create table t2 ( id integer references t1 );
>> /* 1 */ truncate t2;
>> /* 2 */ update t1 set name='foo' where id=1;
> I think what's going on here
"Alexey Nalbat" <[EMAIL PROTECTED]> writes:
> Hello.
>
> I've encountered deadlock with first transaction updating information
> field in the primary table, and second trasaction reloading secondary
> table using TRUNCATE and INSERT. Here is simple example:
>
> create table t1 ( id integer primary
Alexey Nalbat <[EMAIL PROTECTED]> 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;
>
Hello.
I've encountered deadlock with first transaction updating information
field in the primary table, and second trasaction reloading secondary
table using TRUNCATE and INSERT. Here is simple example:
create table t1 ( id integer primary key, name text );
create table t2 ( id integer reference
