Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
psql -8.0.2 INSERT INTO test (code, name ) VALUES ('АБВ', 'Вася'); INSERT INTO test (code, name ) VALUES ('АБВГ', 'Петя'); INSERT INTO test (code, name ) VALUES ('АБВГД', 'Саша'); ERROR: duplicate key violates unique constraint господа, подскажите пожалуйста, почему появляется такая ошибка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 15:28 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
geko wrote: > psql -8.0.2 > > INSERT INTO test (code, name ) VALUES ('АБВ', 'Вася'); > INSERT INTO test (code, name ) VALUES ('АБВГ', 'Петя'); > INSERT INTO test (code, name ) VALUES ('АБВГД', 'Саша'); > > ERROR: duplicate key violates unique constraint > господа, подскажите пожалуйста, почему появляется такая ошибка? Господин, покажите пожалуйста, описание таблицы test Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 15:31 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
create table test ( code char(5) not null, name varchar(100) not null, CONSTRAINT xpktest PRIMARY KEY (code) ); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 15:49 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
Гм, а перед вставкой таблица пустая и таких значений ключей в ней нет? Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 16:40 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
XM Гм, а перед вставкой таблица пустая и таких значений ключей в ней нет? Posted via ActualForum NNTP Server 1.3 да таблица пустая... слушай, а какова вероятность того, что psql не понимает русских букв при написании от руки скрипта через psql? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 16:48 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
geko XM Гм, а перед вставкой таблица пустая и таких значений ключей в ней нет? Posted via ActualForum NNTP Server 1.3 да таблица пустая... слушай, а какова вероятность того, что psql не понимает русских букв при написании от руки скрипта через psql? хотя кодировка базы koi8r, локаль тоже koi8r.... и при 3-х строках INSERT INTO test (code, name ) VALUES ('АБВ', 'Вася'); INSERT INTO test (code, name ) VALUES ('АБВГ', 'Петя'); INSERT INTO test (code, name ) VALUES ('АБВГД', 'Саша'); может 1 insert, а остальные с ошибкой: ERROR: duplicate key violates unique constraint ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 16:51 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
Откуда insert выполняется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 16:59 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
PostgreSQL начинающийОткуда insert выполняется? и ручками выполнялся и файликом выполнялся... эффект одинаковый ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 17:01 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
Странно ... Ошибки быть не должно... Специально попробовал - ситуация описанная выше не воспроизводится.. Все работает как и должно... Вопрос - может есть конкурирущая незавершенная транзакция? Типа добавил - и не закомитил... а в другой транзакции - эти записи не видны - создается впечатление что таблица пустая но при добавлении нарываемся на кронфликт по ключу? Как известно уникальность ключей в индексах проверяется вне транзакции... Может в этом беда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 11:15 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
domanix wrote: > Вопрос - может есть конкурирущая незавершенная транзакция? > Типа добавил - и не закомитил... Тогда бы вторая транзакция ожидала commit первой. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 11:33 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
domanix Вопрос - может есть конкурирущая незавершенная транзакция? Типа добавил - и не закомитил... а в другой транзакции - эти записи не видны - создается впечатление что таблица пустая но при добавлении нарываемся на кронфликт по ключу? низзя сконфликтовать с незавершенной транзакцией, за исключением случая блокировки, но тогда у вас будет не ошибка дубля, а ожидание разблокировки, или максимум - ошибка таймаута в клиенте. Скорее всего афтыр не проверяет пустоту таблы, а гонит пургу, а на деле он уже успел тудыть впиндюлить каку-нть записенку. Хотя и можно допустить, что существует некий неповторимый баг из-за кучи локальных кодировок. domanix Как известно уникальность ключей в индексах проверяется вне транзакции... С этого места поподробнее. По возможности - дайте ссылку. Видимо разработчикам постгреса давно пора застрелицца и не смешить людей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 11:33 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
смотрю: 1. в случае "конфликта" по уникью между двумя транзакциями вторая просто ожидает завершения первой. (не зависит от READ COMMITTED | SERIALIZABLE ) 2. В случае вставки "неконфликтных" записей обе отрабатывают в параллель (т.е. блокировка одной транзакции другой происходит в процессе построения уникального индекса?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 11:55 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
>(т.е. блокировка одной транзакции другой происходит в процессе построения уникального индекса?) Да именно так Версионность есть только у записей.. У ключей индексов версионности нет. Поэтому если ключ уже появился в индексе - то не зависимо от того завершена транзакция или нет - другой записи с таким же ключем вставить не удастся... И действительно - транзакция которая нарвалась на конфликт блокируется пока конкурирующая транзакция не примет решения коммит или ролбак... ИМХО - это нармальная ситуация.. Если вы считаете по другому - то раскажите как по вашему это должно работать? В FirebirdSQL этот механизм работает также - за исключением того что транзакция не блокируется( есть параметр транзакции wait или nowait), и в случае чего откатыватеся конфликтный оператор, а не вся транзакция сразу...... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 12:20 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
domanix ИМХО - это нармальная ситуация.. 1. ИМХО - абсолютно ненормальная. Конфликт должен возникать только при попытке коммита. Как это реализовать - второй вопрос. domanix Если вы считаете по другому - то раскажите как по вашему это должно работать? В FirebirdSQL этот механизм работает также - за исключением того что транзакция не блокируется( есть параметр транзакции wait или nowait), и в случае чего откатыватеся конфликтный оператор, а не вся транзакция сразу......меня, честно говоря, не волнуют проблемы разработчиков. Даже разработчиков "свободного" софта. Есть задача реализовать _нормальное_ поведение транзакции - над ней надо работать. А не достает скилзов или идей - ... дык и облезьян ВЫ ить тожа за людей не признаёте. Интересно спросить о поведении уникью в Оракле. И о механизме реализации версионности индексов в нем. Я к сожалению не в курсе. Если всё так же плёхо - то сталобыть возможно существует органическая проблема версионной организации транзакции, если нет - проблема в конкретных решениях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 12:35 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
ВОт нашел что-то о траблеме "версионности индексов" в Оракле, но не уверен, что фтему softwarerdimitr Мы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи. Вот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:05 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
Я почти не сталкивался с транзакциями. :( Но, по-моему, ситуация нормальная. Ведь одна из конкурирующих транзакциц не отваливается, а "зависает" (лочится). Это может случиться и при работе с таблицами без индексов. 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 ); <ЗАВИСАЕТ> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:08 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
Напосинаю у постргеса версионная архитектура... которая на данный момент есть толкьо у postgres, firebird (interbase),mySQL(innodb) да у MS Yukon будет... В отличии от других серверов записи в версионной архитектуре сразу попадают в таблицу , просто в засисимости от транзакции они видны или не видны.. Поэтому коммит в такой архитектуре ничего не делает - а просто увеличивает внутренний счетчик завершенных транзакций... Если на этом этапе перед коммитом еще запустить механизм проверки уникальности - то это в большинстве ситуций будет довольно большой излишней нагрузкой... Но если вам очень надо - то разработчики постгреса оставили для вас возможность включить механимзм проверки после коммита... смотрите например комманду SEt CONTARINT в части модификаторов DEFERRED | IMMEDIATE IMMEDIATE constraints are checked at the end of each statement. DEFERRED constraints are not checked until transaction commit. Each constraint has its own IMMEDIATE or DEFERRED mode. по моему это то что вам нужно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:08 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
4321ВОт нашел что-то о траблеме "версионности индексов" в Оракле, но не уверен, что фтему softwarerdimitr Мы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи. Вот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах.Здесь вроде бы о возможности index scan без заглядывания в таблицу, которая есть в оракле. В постгресе нету. (При выборках, это не касается транзакций.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:15 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatПри выборках, это не касается транзакций.Глупость сморозил. При выборках. Но как раз транзакций и видимости записей это касается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:22 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
domanix wrote: > Если на этом этапе перед коммитом еще запустить механизм проверки > уникальности - то это в большинстве ситуций будет довольно большой > излишней нагрузкой... > Но если вам очень надо - то разработчики постгреса оставили для вас > возможность > включить механимзм проверки после коммита... > смотрите например комманду SEt CONTARINT в части модификаторов DEFERRED > | IMMEDIATE > IMMEDIATE constraints are checked at the end of each statement. DEFERRED > constraints are not checked until transaction commit. Each constraint > has its own IMMEDIATE or DEFERRED mode. > по моему это то что вам нужно... Фиг там. UNIQUE и CHECK констрейнты в PostgreSQL отложить низзя. Это давний известный баг, из-за которого и UPDATE не всегда атомарный. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 13:22 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
domanixСтранно ... Ошибки быть не должно... Специально попробовал - ситуация описанная выше не воспроизводится.. Все работает как и должно... Вопрос - может есть конкурирущая незавершенная транзакция? Типа добавил - и не закомитил... а в другой транзакции - эти записи не видны - создается впечатление что таблица пустая но при добавлении нарываемся на кронфликт по ключу? Как известно уникальность ключей в индексах проверяется вне транзакции... Может в этом беда? а попробуй так: INSERT INTO test (code, name ) VALUES ('А01', 'Вася'); INSERT INTO test (code, name ) VALUES ('А02', 'Петя'); INSERT INTO test (code, name ) VALUES ('Б01', 'Саша'); INSERT INTO test (code, name ) VALUES ('Б02', 'Саша'); INSERT INTO test (code, name ) VALUES ('В01', 'Саша'); INSERT INTO test (code, name ) VALUES ('В02', 'Саша'); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 14:50 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
Все равно - не воспроизводится... у меня 8.1b3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 15:34 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
А база с какими настройками создана? charset какой? может и правда тут собака зарыта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 15:38 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
XMФиг там. UNIQUE и CHECK констрейнты в PostgreSQL отложить низзя. Это давний известный баг, из-за которого и UPDATE не всегда атомарный. Posted via ActualForum NNTP Server 1.3именно из-за неверсионности индексов отложить UNIQUE не удасца. И именно поэтому перед апдейтом скажем id=id+1 приходица отсортировывать набор (т.е. проворачивать его в ф-ии пробегом по сортированному набору). 2 LeXa NalBat Конкретно там (по сноске) - да - речь об индекс-скане. Но тот же механизм (если я его правильно просек) позволил бы развязать проблему проверки уникью по выходу (а не внутри транзакции - на каждой строке) - т.е. преодолеть тот же баг атомарности апдейта, и он же позволил бы развязать конкурирующие за некое значение уникью транзакции. (т.е. - "кто первый закоммитил - тот и прав, а тот, кто покурить вышел - _никого_не_держит, но получит отлуп при попытке коммита"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 16:52 |
|
||
|
ERROR: duplicate key violates unique constraint
|
|||
|---|---|---|---|
|
#18+
psql 8.0.2 база - KOI8 локаль LANG=ru_RU.koi8r LC_CTYPE="ru_RU.koi8r" LC_NUMERIC="ru_RU.koi8r" LC_TIME="ru_RU.koi8r" LC_COLLATE="ru_RU.koi8r" LC_MONETARY="ru_RU.koi8r" LC_MESSAGES="ru_RU.koi8r" LC_PAPER="ru_RU.koi8r" LC_NAME="ru_RU.koi8r" LC_ADDRESS="ru_RU.koi8r" LC_TELEPHONE="ru_RU.koi8r" LC_MEASUREMENT="ru_RU.koi8r" LC_IDENTIFICATION="ru_RU.koi8r" LC_ALL= и все равно не дает сделать первичным ключом русские буквы :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 16:54 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33332523&tid=2006915]: |
0ms |
get settings: |
10ms |
get forum list: |
23ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
56ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
84ms |
get tp. blocked users: |
1ms |
| others: | 258ms |
| total: | 459ms |

| 0 / 0 |
