удалось поставить Постгрес (9.3.?) в позу:



вопрос: куда копать ?
что наиболее чревато "Segmentation fault"-ами ?
есть какие-то общие рекомендации ?

Гость_0какабычна,

возможно какой-то внешний модуль использовался в этом запросе.

ближе к телу -- посмотрю

пока, по памяти : -- это пишущая в 1-2 (до 3-х ) таблы
[в зависимости от параметров]
функция (хранимка)

если правильно помню -- голый sql + plpgsql
буквально

должна дергаться часто, 10-ки 1000 раз на день.
падает значительно реже.
неужто есть такое редкое совпадение параметров. с которыми вызывается раз в 2-3 дня ?

надо, конечно, проверить, не дергается ли там что со стороны

из отягчающих -- триггера на вставляемых/изменяемых таблицах (партицирование, материализация)

возникло:

SELECT version()
--"PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit"
--боевой

воспроизводится (не 100 %, но воспроизводится)
--"PostgreSQL 9.2.8 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52), 64-bit"
--тесты и разработка


нащупал, что
проблема в материализации триггерами (есть константа, которая её отключает -- обходит в коде)

в реальности там всё сложно устроено

вкратце:
таблицы мастер + слейв (по 5-10 записей на ключ мастера)
+ "мат представление" , собираемое триггерами И с того И с этого [что очень напрягает даже интуитивно]. (AFTER i,a,d; on each row)
//партицировано по дате, живет месяц-другой//

в мат представл. кроме полей мастера -- массивы ARRAY(SELECT field FROM slave WHERE id_master=:id_master)
по всей этой бодяге -- индексы . пока обычные btree. (функциональные по массивам, но по ф-ям, возвращающим скаляры, составные с ними[ф-ями], условные с ними[же]).

удается положить, когда конкурентно 2*{апдейтим мастера и пишем в слейва} в 2-х разных транзакциях.
на роллбаке не упал ни разу.
на коммите первой транзакции положил тест несколько раз (вторая валится, после успеха первой) , но всегда при пустых, перед тестом, массивах в полях-агрегатах.
При непустых массивах (<>{}) в матвью положить пока не получилось.

в общем, попытаюсь накидать тест-кейс попроще. чуть позже.


но в любом случае, надо бы как-то изменить способ сбора мат-вьюхи (оставаясь в актуальном состоянии). там из-за этих триггеров и другие проблемы есть (в моем случае не мешают, но в общем -- всё плохо). -- интересуют сакскесс-стори (такой материализации). Они есть?

PS упустил -- в конкурентных транзах боремся за одну запись мат-вью (master_id).
порядок обработки в каждой транзе -- сначала пишем апдейт мастера, потом -- инсерт в слейв (оба-2 стейтмента запускают свои row-триггера, ессно)

продолжу мысль:
какабычнаPS упустил -- в конкурентных транзах боремся за одну запись мат-вью (master_id).
порядок обработки в каждой транзе -- сначала пишем апдейт мастера, потом -- инсерт в слейв (оба-2 стейтмента запускают свои row-триггера, ессно)
поэтому 2-я транзакция всегда ждет коммита всей первой уже на первом пишущем стейтменте. Иди вернее - должна.