Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements

Поиск
Список
Период
Сортировка
От trafdev
Тема Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements
Дата
Msg-id 6dfedd82-c977-0d73-7de3-c1c62d18e44a@mail.ru
обсуждение исходный текст
Ответ на Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements  (trafdev <trafdev@mail.ru>)
Ответы Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
I've also replaced "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt})
{ins_stmt}" to "INSERT INTO .. ON CONFLICT DO UPDATE ...", but no
success - row level deadlocks still occur...
Is there a way to tell Postgres to update rows in a specified order?
Or maybe LOCK TABLE should be used?

> Sessions are running concurrently because of flexibility - they are two
> different scheduled jobs launching at different times and performing
> different set of operations.
>
> Of course I can play with scheduling timings and make them not intersect
> with each other (which I've done already btw), but that's only a temp
> solution.
>
> So how in PostgreSQL-world 2 or more transactions can update the same
> table without deadlocking? I can't believe it's not possible, there must
> be some sort of synchronization primitive. Does it support a "named
> mutex" concept from a system-programming world? I bet there is something
> more suitable.


В списке pgsql-general по дате отправления:

Предыдущее
От: trafdev
Дата:
Сообщение: Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements
Следующее
От: Andy Colson
Дата:
Сообщение: 9.3 to 9.5 upgrade problems