N
если в первом случе я тупо складывал базу и водил ее в рековери мод, то во втором - я просто получал отлуп и законный ролбек транзакции.
Size: a a a
2020 July 21
N
но хочется как то и этот отлуп не получать
В
Yaroslav Schekin
Хмм... а какое там исключение бросается? Насколько сложно сделать repro?
22P02 : invalid input syntax for type json
в консоль пишет а в таблицу ошибок назначенную в обработчике исключений не пишет
думаю дело в том что ловить нужно как то по особенному
в консоль пишет а в таблицу ошибок назначенную в обработчике исключений не пишет
думаю дело в том что ловить нужно как то по особенному
YS
Я их повторяю, это да. Я читал, что в PG 11 вроде появились процедуры и функции и разница там как раз в уровне изоляции данных. И показалось, что может я использую процедуры, а нужно функции.
Процедуры всего лишь позволяют управлять транзакциями в простых случаях.
> что может я использую процедуры, а нужно функции.
Так у Вас функция или процедура?
И по блокированию (если Вы почему-то хотите заняться deadlock avoidance):
Если так, то блокирование другой может оказаться лечением головной боли гильотиной (другие запросы к ней заблокируете, особенно те, которые вообще не имели отношения к этому deadlock).
> что может я использую процедуры, а нужно функции.
Так у Вас функция или процедура?
И по блокированию (если Вы почему-то хотите заняться deadlock avoidance):
CONTEXT: while updating tuple (935,46) in relation "storehouse_remain"Проблема-то, вроде бы, с этой таблицей?
Если так, то блокирование другой может оказаться лечением головной боли гильотиной (другие запросы к ней заблокируете, особенно те, которые вообще не имели отношения к этому deadlock).
YS
жесткий был такой -
потом я подкорретировал настроки базы под размер cpu и ram сервера.
ситуация улучшилась, но все равно
DE
server process (PID 464) was terminated by signal 9: Killed
Failed process was running: INSERT INTO assignment AS "t" (...
terminating any other active server processes
потом я подкорретировал настроки базы под размер cpu и ram сервера.
ситуация улучшилась, но все равно
DE
TAIL: Cannot enlarge string buffer containing 0 bytes by 1165680927 more bytes.и постоянно перенастраивать код под ресурсы базы - не комильфо. думал как то (хотя бы примерно) оценить тяжесть вставки. и перед вставкой его почикать на куски подходящие.
Первое похоже на OOM kill (проверьте логи системы) — если так, проблема тут с неправильной настройкой OS (что-то делать с PostgreSQL тут не поможет).
> потом я подкорретировал настроки базы под размер cpu и ram сервера.
Если причина — OOM kill, это не даст никаких гарантий. См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
> TAIL: Cannot enlarge string buffer containing 0 bytes by 1165680927 more bytes.
Вот тут стоит посмотреть подробнее — что за запрос выполнялся, может быть, "вытащить" его, воспроизвести ситуацию и понять, что и где там выделяется.
> потом я подкорретировал настроки базы под размер cpu и ram сервера.
Если причина — OOM kill, это не даст никаких гарантий. См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
> TAIL: Cannot enlarge string buffer containing 0 bytes by 1165680927 more bytes.
Вот тут стоит посмотреть подробнее — что за запрос выполнялся, может быть, "вытащить" его, воспроизвести ситуацию и понять, что и где там выделяется.
В
Добрый вечер. Перевел бизнес логику в хранимые процедуры и стал отлавливать такое
Я так понимаю, что перед тем, как делать SELECT SUM(iu.weight) FROM storehouse_itemusage iu
WHERE iu.item_id = rec.item_id AND iu.storehouse_id = rec.storehouse_id AND iu.type = 'u'
AND iu.created_at >= r.created_at
нужно эти записи залочить
ERROR: deadlock detected
DETAIL: Process 16867 waits for ShareLock on transaction 20266082; blocked by process 17093.
Process 17093 waits for ShareLock on transaction 20266035; blocked by process 16867.
HINT: See server log for query details.
CONTEXT: while updating tuple (935,46) in relation "storehouse_remain"
SQL statement "UPDATE storehouse_remain r SET outgo = COALESCE(
(SELECT SUM(iu.weight) FROM storehouse_itemusage iu
WHERE iu.item_id = rec.item_id AND iu.storehouse_id = rec.storehouse_id AND iu.type = 'u'
AND iu.created_at >= r.created_at), 0)
WHERE r.id = remain_id"
PL/pgSQL function update_remain_outgo() line 12 at SQL statement
SQL statement "DELETE FROM storehouse_itemusage WHERE referrer_id = referrerid"
Я так понимаю, что перед тем, как делать SELECT SUM(iu.weight) FROM storehouse_itemusage iu
WHERE iu.item_id = rec.item_id AND iu.storehouse_id = rec.storehouse_id AND iu.type = 'u'
AND iu.created_at >= r.created_at
нужно эти записи залочить
Посмотрел Ваш код, как то на хранимые процедуры не похоже, помоему это чистый sql. Так на каком языке пишите ?
YS
22P02 : invalid input syntax for type json
в консоль пишет а в таблицу ошибок назначенную в обработчике исключений не пишет
думаю дело в том что ловить нужно как то по особенному
в консоль пишет а в таблицу ошибок назначенную в обработчике исключений не пишет
думаю дело в том что ловить нужно как то по особенному
Да, вроде бы, нет... Тут бы код посмотреть и т.п. (я понимаю, что с dblink это не так просто показать, но всё-таки).
N
Yaroslav Schekin
Первое похоже на OOM kill (проверьте логи системы) — если так, проблема тут с неправильной настройкой OS (что-то делать с PostgreSQL тут не поможет).
> потом я подкорретировал настроки базы под размер cpu и ram сервера.
Если причина — OOM kill, это не даст никаких гарантий. См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
> TAIL: Cannot enlarge string buffer containing 0 bytes by 1165680927 more bytes.
Вот тут стоит посмотреть подробнее — что за запрос выполнялся, может быть, "вытащить" его, воспроизвести ситуацию и понять, что и где там выделяется.
> потом я подкорретировал настроки базы под размер cpu и ram сервера.
Если причина — OOM kill, это не даст никаких гарантий. См. https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT
> TAIL: Cannot enlarge string buffer containing 0 bytes by 1165680927 more bytes.
Вот тут стоит посмотреть подробнее — что за запрос выполнялся, может быть, "вытащить" его, воспроизвести ситуацию и понять, что и где там выделяется.
ну да, с первым согласен, и я от него ушел.
со вторым - план запроса посмотреть?
я пока играюсь с количеством строк в одном инсерте, но как не хочу играть в магические числа, которые через полгода меня же подведут
со вторым - план запроса посмотреть?
я пока играюсь с количеством строк в одном инсерте, но как не хочу играть в магические числа, которые через полгода меня же подведут
YS
ну да, с первым согласен, и я от него ушел.
со вторым - план запроса посмотреть?
я пока играюсь с количеством строк в одном инсерте, но как не хочу играть в магические числа, которые через полгода меня же подведут
со вторым - план запроса посмотреть?
я пока играюсь с количеством строк в одном инсерте, но как не хочу играть в магические числа, которые через полгода меня же подведут
> со вторым - план запроса посмотреть?
Да сначала хотя бы ошибку воспроизвести. Нет там никаких "магических чисел" при вставке, понимаете? ;)
Хоть сотни гигабайт в одной транзакции можно в базу "залить", PostgreSQL это должен нормально обрабатывать.
Поэтому я и пишу, что тут что-то не так / нужно искать причину.
Да сначала хотя бы ошибку воспроизвести. Нет там никаких "магических чисел" при вставке, понимаете? ;)
Хоть сотни гигабайт в одной транзакции можно в базу "залить", PostgreSQL это должен нормально обрабатывать.
Поэтому я и пишу, что тут что-то не так / нужно искать причину.
N
Yaroslav Schekin
> со вторым - план запроса посмотреть?
Да сначала хотя бы ошибку воспроизвести. Нет там никаких "магических чисел" при вставке, понимаете? ;)
Хоть сотни гигабайт в одной транзакции можно в базу "залить", PostgreSQL это должен нормально обрабатывать.
Поэтому я и пишу, что тут что-то не так / нужно искать причину.
Да сначала хотя бы ошибку воспроизвести. Нет там никаких "магических чисел" при вставке, понимаете? ;)
Хоть сотни гигабайт в одной транзакции можно в базу "залить", PostgreSQL это должен нормально обрабатывать.
Поэтому я и пишу, что тут что-то не так / нужно искать причину.
даже если размер данных у вставляемых данных (с учетом генерации индексов) будет меньше, чем сервер имеет рамы например?
YS
даже если размер данных у вставляемых данных (с учетом генерации индексов) будет меньше, чем сервер имеет рамы например?
Да хоть в сто раз больше — какая разница? ;)
N
Yaroslav Schekin
Да хоть в сто раз больше — какая разница? ;)
я почему то думал что не сможет
АЛ
даже если размер данных у вставляемых данных (с учетом генерации индексов) будет меньше, чем сервер имеет рамы например?
Будет на диск в pg_tmp писать
N
Будет на диск в pg_tmp писать
запомнил, спс
YS
Будет на диск в pg_tmp писать
Зачем ему писать в pg_tmp? В случае обычного INSERT туда не попадёт ничего.
АЛ
Сбило меня с толку надпись про генерацию индексов
АЛ
Перечитал - неправ )
АЛ
даже если размер данных у вставляемых данных (с учетом генерации индексов) будет меньше, чем сервер имеет рамы например?
И тут видимо имелось ввиду "больше чем RAM"
YS
я почему то думал что не сможет
Да нет, как и любой (?) disk-based DBMS — главное, чтобы места на диске хватило.
АЛ
Ярослав, а какой алгоритм будет при вставке такой большой пачки данных?