Re: Blocking Issue

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 one transaction 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