Я почти не сталкивался с транзакциями. :( Но, по-моему, ситуация нормальная. Ведь одна из конкурирующих транзакциц не отваливается, а "зависает" (лочится). Это может случиться и при работе с таблицами без индексов.

1=> create table test ( foo integer );
CREATE TABLE
1=> insert into test values ( 1 );
INSERT 68935894 1
1=> begin;
BEGIN

2=> begin;
BEGIN
2=> update test set foo=2;
UPDATE 1

1=> update test set foo=3;
<ЗАВИСАЕТ>

P.S.: Вот, если я правильно понял, ваш эксперимент на постгресе и оракле (старом, другого нету). Поведение одинаковое.

PostgreSQL 8.0.3

1=> create table test ( id integer not null primary key );
NOTICE: CREATE TABLE / PRIMARY KEY создаст подразумеваемый индекс "test_pkey" для таблицы "test"
CREATE TABLE
1=> begin;
BEGIN
1=> insert into test values ( 1 );
INSERT 68935899 1
1=> insert into test values ( 2 );
INSERT 68935900 1

2=> begin;
BEGIN
2=> insert into test values ( 3 );
INSERT 68935901 1
2=> insert into test values ( 2 );
<ЗАВИСАЕТ>

Oracle 8.1.7

1> create table test ( id integer not null primary key );
Table created.

2> insert into test values ( 1 );
1 row created.
2> insert into test values ( 2 );
1 row created.

1> insert into test values ( 3 );
1 row created.
1> insert into test values ( 2 );
<ЗАВИСАЕТ>

4321ВОт нашел что-то о траблеме "версионности индексов" в Оракле, но не уверен, что фтему
softwarerdimitr
Мы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи.

Вот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах.Здесь вроде бы о возможности index scan без заглядывания в таблицу, которая есть в оракле. В постгресе нету. (При выборках, это не касается транзакций.)

LeXa NalBatПри выборках, это не касается транзакций.Глупость сморозил. При выборках. Но как раз транзакций и видимости записей это касается.

4321Конкретно там (по сноске) - да - речь об индекс-скане. Но тот же механизм (если я его правильно просек) позволил бы развязать проблему проверки уникью по выходу (а не внутри транзакции - на каждой строке) - т.е. преодолеть тот же баг атомарности апдейта, и он же позволил бы развязать конкурирующие за некое значение уникью транзакции. (т.е. - "кто первый закоммитил - тот и прав, а тот, кто покурить вышел - _никого_не_держит, но получит отлуп при попытке коммита").Даже боюсь размышлять о таких высоких материях со своей дилетантской позиции, потому что почти наверняка упущу какую-нибудь важную тонкость. Но, как я показал на примере, у древнего оракла (в котором тем не менее индекс скан есть) поведение аналогичное - транзакция зависает, а не получает отлуп при попытке коммита, как вы предлагаете. Правда, иное поведение у транзакции после зависания, если конкурирующую завершили коммитом. В постгресе отваливается вся транзакция - надо делать роллбэк, а в оракле только висевший стэйтмент, транзакцию можно продолжать.

4321уникью обчий и в оракле для усих транзакций?Каким экспериментом это можно проверить?
4321И что, отложить уникью в ём тоже низзя?Судя по доке можно. (Для доступа требуется регистрация.)

gekoГоспода,
значит не видать мне первичного ключа русскими буковками да?
ERROR: повторный ключ нарушает констрейнт UNIQUE "xpktest"У меня ошибки не наблюдается. PostgreSQL 8.0.3.

=> create table test (
(> code char(5) not null,
(> name varchar(100) not null,
(> CONSTRAINT xpktest PRIMARY KEY (code)
(> );
NOTICE: CREATE TABLE / PRIMARY KEY создаст подразумеваемый индекс "xpktest" для таблицы "test"
CREATE TABLE
=> INSERT INTO test (code, name ) VALUES ('АБВ', 'Вася');
INSERT 68935916 1
=> INSERT INTO test (code, name ) VALUES ('АБВГ', 'Петя');
INSERT 68935917 1
=> INSERT INTO test (code, name ) VALUES ('АБВГД', 'Саша');
INSERT 68935918 1
=> INSERT INTO test (code, name ) VALUES ('АБВГДЕ', 'Маша');
ERROR: значение велико для типа character(5)
=> select * from test;
code | name
-------+------
АБВ | Вася
АБВГ | Петя
АБВГД | Саша
(3 rows)

Наверное у вас проблема в настройках ОС или постгреса.

gekoА какая у тебя OC?
может настройками поделишься?
может нам стоит с Вами настройки постргереса сравнить?У нас сисадмин занимается установкой оси, постгреса и других вещей. Я в этом почти не разбираюсь. :( Выполнить команду и показать ее выдачу могу. Какую команду? :)

Ось:
~$ uname
Linux

max_connections = 100
shared_buffers = 1000 # min 16, at least max_connections*2, 8KB each
effective_cache_size = 8192 # typically 8KB each
stats_command_string = true
lc_messages = 'ru_RU.cp1251' # locale for system error message strings
lc_monetary = 'ru_RU.cp1251' # locale for monetary formatting
lc_numeric = 'ru_RU.cp1251' # locale for number formatting
lc_time = 'ru_RU.cp1251' # locale for time formatting

База создавалась: create database ... with encoding 'WIN-1251';