From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Alexey Nalbat" <nalbat(at)price(dot)ru>, pgsql-general(at)postgresql(dot)org, developers(at)price(dot)ru |
Subject: | Re: deadlock with truncate and foreing keys |
Date: | 2008-02-18 20:58:52 |
Message-ID: | 975.1203368332@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Alexey Nalbat" <nalbat(at)price(dot)ru> 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 is that in transaction 1 the TRUNCATE locks t2
> and then the INSERT tries to take a lock on a record in t1 to enforce the
> referential integrity.
I'm not sure whether the OP recognizes that this is a critical point,
but that UPDATE isn't changing t1.id and therefore there is no need
for it to look into t2 at all. The current code in fact does not look
into t2, much less take any row-level lock there; but nonetheless it
transiently takes AccessShareLock on t2. I'm thinking that might be
unnecessary ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-02-18 21:11:20 | Re: Initdb failed in PostgreSQL 7.3.21 |
Previous Message | Scott Marlowe | 2008-02-18 20:57:48 | Re: Initdb failed in PostgreSQL 7.3.21 |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2008-02-18 20:59:29 | Re: CVS repository invalid revision |
Previous Message | Gregory Stark | 2008-02-18 20:32:25 | Re: deadlock with truncate and foreing keys |