Re: Blocking Issue

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Blocking Issue
Дата
Msg-id 4D527553.1070409@enterprisedb.com
обсуждение исходный текст
Ответ на Blocking Issue  ("Sander, Ingo (NSN - DE/Munich)" <ingo.sander@nsn.com>)
Список 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 по дате отправления:

Предыдущее
От: "Sander, Ingo (NSN - DE/Munich)"
Дата:
Сообщение: Blocking Issue
Следующее
От: Itagaki Takahiro
Дата:
Сообщение: Re: Transaction-scope advisory locks