|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Собственно есть ли лекарство от этого кроме предусмотрительности программиста? Скажем, указанное в конфиге, ограничение количества вызовов или ещё чего. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2019, 13:42 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
sergnn, https://postgrespro.ru/docs/postgresql/11/trigger-definition Если триггерная функция выполняет команды SQL, эти команды могут заново запускать триггеры. Это известно как каскадные триггеры. Прямых ограничений на количество каскадных уровней не существует. Вполне возможно, что каскадные вызовы приведут к рекурсивному срабатыванию одного и того же триггера. Например, в триггере INSERT может выполняться команда, которая добавляет строку в эту же таблицу, тем самым опять вызывая триггер на INSERT. Обязанность программиста не допускать бесконечную рекурсию в таких случаях. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2019, 14:04 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Павел Лузанов, оно конечно спасибо, но именно это я уже читал. Просто обычно с СУБД такое не допускается средствами самой БД. В Оракуле, например из строкового триггера просто невозможно обратиться к таблице этого триггера, а в SYBASE количесто рекурсий ограничивается на уровне конфигурации. Печально что в PG ничего не предусмотрено. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2019, 12:52 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
sergnn, А что в Sybase происходит при достижении установленного в конфигурации лимита? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2019, 14:26 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Павел Лузановsergnn, А что в Sybase происходит при достижении установленного в конфигурации лимита? Исключение и откат транзакции. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 09:24 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
sergnn, В постгресе также возникнет ошибка и откат оператора, что вызовет откат транзакции. Только лимит на рекурсию не настраивается. Но что дает настройка лимита? С лимитом или без, но триггер написан неправильно и разработчик должен переписать код. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 10:31 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Павел Лузанов, если откат транзакции происходит, то когда? если не настроено количество рекурсий? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:54 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Павел Лузанов, Понятно что разработчик должен переписать код, но если триггер войдёт в бесконечную рекурсию, то что тогда? Базу перезагружать? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 11:56 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
sergnnПавел Лузанов, Понятно что разработчик должен переписать код, но если триггер войдёт в бесконечную рекурсию, то что тогда? Базу перезагружать? Упрётся в max_stack_depth и прервётся с рядовым ERROR "stack depth limit exceeded". Если настроен неадекватно - то грохнется backend от SIGSEGV и база уйдёт в перезапуск (при включенном restart_after_crash) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 12:53 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
MelkijsergnnПавел Лузанов, Понятно что разработчик должен переписать код, но если триггер войдёт в бесконечную рекурсию, то что тогда? Базу перезагружать? Упрётся в max_stack_depth и прервётся с рядовым ERROR "stack depth limit exceeded". Если настроен неадекватно - то грохнется backend от SIGSEGV и база уйдёт в перезапуск (при включенном restart_after_crash) Круто. По мне так логичнее было бы как-то ограничить количество рекурсий, либо уж как Оракул обрубить обращение к собственной таблице. Но имеем что имеем... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 15:59 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
sergnn, Это может происходить только при тестировании разработчиком, но не на боевой базе. Что хорошего в том, что на боевой базе кривой код (а ведь он кривой) выполнится неправильно "всего" сто раз? Обрабатывать ошибку и продолжать? Крайне странно, хотя возможно чего-то не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2019, 20:33 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
<Взгляд со стороны> Павел ЛузановЭто может происходить только при тестировании разработчиком, но не на боевой базе.Разработчики не боги и вполне могут чего-то не предусмотреть, что стрелнёт только на проде. Это же не повод пожирать ресурсы и падать с непонятной ошибкой.Павел Лузановхотя возможно чего-то не понимаю.Не дай бог, чтоб разработчик был правильным и писал логи на каждом уровне... </Взгляд со стороны> ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2019, 08:25 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Elic, ары-калоеды, дуйте в свою сракл-песочницу которая даже рукопашное дерево триггерно не поддержит, при такой странной надобности https://postgrespro.ru/docs/postgresql/11/runtime-config-resource max_stack_depth (integer) Задаёт максимальную безопасную глубину стека для исполнителя. В идеале это значение должно равняться предельному размеру стека, ограниченному ядром (как устанавливает команда ulimit -s или равнозначные ей), за вычетом запаса примерно в мегабайт. Этот запас необходим, потому что сервер проверяет глубину стека не в каждой процедуре, а только в потенциально рекурсивных процедурах, например, при вычислении выражений. Значение по умолчанию — два мегабайта (2MB), выбрано с большим запасом, так что риск переполнения стека минимален. Однако, с другой стороны, его может быть недостаточно для выполнения сложных функций. Изменить этот параметр могут только суперпользователи. Если max_stack_depth будет превышать фактический предел ядра, то функция с неограниченной рекурсией сможет вызвать крах отдельного процесса сервера. В системах, где PostgreSQL может определить предел, установленный ядром, он не позволит установить для этого параметра небезопасное значение. Однако эту информацию выдают не все системы, поэтому выбирать это значение следует с осторожностью. как видим -- есть ручка для предотвращения. нужно только ознакомиться. а в других случаях (кроме обслуги графов) -- триггерная рекурсия -- даже не ошибка, а идиотизм разработчика а сракл я примитивным запросом в ора600 вгонял. синтаксически верным, что интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2019, 10:30 |
|
Бесконечная рекурсия в триггерах.
|
|||
---|---|---|---|
#18+
Elic, Обладеть, какие люди! Рад видеть в этом форуме. Помню в oraclе "грамотные" разработчики уже давно приладились обращаться к мутирующей таблице в автономной транзакции )) Как по мне, так пусть лучше сервер навернется, но согласованность данных не нарушится. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.04.2019, 11:55 |
|
|
start [/forum/topic.php?fid=53&msg=39804791&tid=1995228]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 163ms |
0 / 0 |