Re: Blocking Issue - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Blocking Issue
Date
Msg-id 4D527553.1070409@enterprisedb.com
Whole thread Raw
In response to Blocking Issue  ("Sander, Ingo (NSN - DE/Munich)" <ingo.sander@nsn.com>)
List pgsql-hackers
On 09.02.2011 12:15, Sander, Ingo (NSN - DE/Munich) wrote:
> Hi,
> I have create the following tables:
> 1. rnc table
> CREATE TABLE act_rnc(rnc_id integer NOT NULL PRIMARY KEY, rnc_data BYTEA);
> 2. rncgen table
> CREATE TABLE act_rncgen(rnc_id integer NOT NULL PRIMARY KEY, rncsubObj_Cnt integer, rncgen_data BYTEA);
> 3. iuo table which has a foreign key reference to rnc table
> CREATE TABLE act_iuo(iuo_id integer NOT NULL primary key, rnc_id integer NOT NULL, iuo_data BYTEA, FOREIGN
KEY(rnc_id)references act_rnc(rnc_id) on delete cascade);
 
>
> Now i open two transactions (separate session with psql). In the first transaction I give the following sql
sequence:
> begin;
> update act_rnc set rnc_data='rnc_data' where rnc_id=1;
>
> The transaction will be open.
>
> In a second transaction i give the following sql sequence:
> begin;
> insert into act_iuo values (1,1,'iuo_data');
>
> -->  now the second transaction is blocked. I work with PostgreSQL 9.0.
> ...
>
> I assume that the access to act_rnc_pkey causes the blocking, however why? Or how I can resolve the blocking (commit
onetransaction solves the problem, but should Postgres not recognize the blocking situation and release one
transaction?).Is this an error in Postgres?
 

The foreign key causes the blocking. PostgreSQL doesn't make a 
distinction on which columns are updated, as far as locking is 
concerned. If the update was "update act_rnc set rnc_id=2 where 
rnc_id=1", the insert would have to block to see if the update commits 
or not - if it commits the insert would violate the foreign key and 
needs to be aborted, but if it aborts the insert can succeed. With your 
original example, the insert could go ahead in either case without 
violating the foreign key, since the update doesn't change rnc_id field, 
but PostgreSQL doesn't pay attention to that detail.

There's actually a patch in the current commitfest, awaiting review, to 
address exactly that scenario. See 
https://commitfest.postgresql.org/action/patch_view?id=502 and 
http://archives.postgresql.org/message-id/1294953201-sup-2099@alvh.no-ip.org.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Sander, Ingo (NSN - DE/Munich)"
Date:
Subject: Blocking Issue
Next
From: Itagaki Takahiro
Date:
Subject: Re: Transaction-scope advisory locks