Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Обработка ошибок в plpgsql / 8 сообщений из 8, страница 1 из 1
20.02.2005, 18:48
    #32925129
Вячеслав Скорых
Вячеслав Скорых
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
Допустим, внутри процедуры выполняется оператор insert и существует вероятность, что вставляемая запись уже существует в таблице. Как данную ситуацию корректно обработать в plpgsql? Существуют ли средства, аналогичные тем, что предоставляет Oracle и Interbase?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2005, 03:21
    #32925240
фффф
фффф
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
35.7.5. Trapping Errors
+универсальный способ - проверять перед вставкой.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2005, 08:58
    #32925350
Вячеслав Скорых
Вячеслав Скорых
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
За ссылку однозначно спасибо. Что касается совета проверять перед вставкой - это плохой совет. Это работает, но не всегда.

К примеру, вчера я завел таблицу с полями id и name. По name сделал уникальный индекс. Если проверять наличие записи, а затем делать вставку, то при обычной нагрузке все работает, а вот когда я пустил 100 потоков параллельно, то получил весьма нехилое количество попыток создать дубликаты по полю name. То есть после того как один из потоков установил тот факт, что некая запись отсутствует, другой поток сделал commit, и операция вставки для первого потока обломилась.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2005, 10:48
    #32925543
assa
assa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
Вячеслав СкорыхЗа ссылку однозначно спасибо. Что касается совета проверять перед вставкой - это плохой совет. Это работает, но не всегда.

К примеру, вчера я завел таблицу с полями id и name. По name сделал уникальный индекс. Если проверять наличие записи, а затем делать вставку, то при обычной нагрузке все работает, а вот когда я пустил 100 потоков параллельно, то получил весьма нехилое количество попыток создать дубликаты по полю name. То есть после того как один из потоков установил тот факт, что некая запись отсутствует, другой поток сделал commit, и операция вставки для первого потока обломилась.
если вставка из другой таблицы - обычно так (в одном флаконе)
Код: plaintext
INSERT INTO a FROM b LEFT JOIN a AS a0  USING (name) WHERE a0.name IS NULL;
если из данных - можно так же (т.е.)
Код: plaintext
... FROM (SELECT 'xxx' AS name, xxx AS xxx ) AS b LEFT JOIN a AS a0  ...
а можно в транзакции с блокировками
Код: plaintext
1.
2.
3.
4.
5.
BEGIN;
LOCK xxxxx ;
IF {Test};
  INSERT xxx;
END IF;
COMMIT;
а вообще-то отлуп на вставку - нормальная ситуация - тапки ушли - твое дело отлуп обработать (дать другие тапки / не давать тапок) - от логики.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.02.2005, 11:05
    #32925589
Вячеслав Скорых
Вячеслав Скорых
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
assaа вообще-то отлуп на вставку - нормальная ситуация - тапки ушли - твое дело отлуп обработать (дать другие тапки / не давать тапок) - от логики.

Полностью согласен. Потому-то я и заинтересовался, в первую очередь, штатными средствами обработки таких ситуаций в plpgsql. Было бы обидно, если бы их не оказалось.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
26.02.2008, 05:24
    #35154269
_PG_
_PG_
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
Присоединяюсь к вопросу. На выходе должны получить максимально быстродействующую и легкую вставку в базу при, скажем, при 500 клиентах.
Ситуации:
1) Есть таблица, комбинация полей в которой должна быть уникальна.
Решения:
Уникальный индекс. - Какие подводные камни? Как уникальный индекс влияет на скорость вставки?
Блокировка таблицы - не подходит. Работа клиентов станет последовательной.
Уровень изоляции транзацкции?

2) Тоже самое, только ввиду огромного размера таблицы уникальность нужно проверить за последние 7 дней.
Уникальный индекс уже не подходит. Делать партиционирование? Накладывать ограничение уникальным индексом на "текущую" партицию?

Кто сталкивался с подобными задачами - раскажите пожалуйста как решаются данные задачи? Заранее благодарен!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.02.2008, 12:25
    #35157514
raist
raist
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
Хм...странно почему никто не посоветовал использовать ексепшены? Например
Begin
Код: plaintext
1.
2.
3.
4.
INSERT INTO table VALUES(bla,bla,bla);
EXCEPTION
WHEN unique_violation THEN
NULL;
END;
Вот
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.02.2008, 14:04
    #35157855
4321
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обработка ошибок в plpgsql
raistХм...странно почему никто не посоветовал использовать ексепшены?
вы невнимательны: http://sql.ru/forum/actualthread.aspx?tid=161470#1334009
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Обработка ошибок в plpgsql / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]