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
|
Список | 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 по дате отправления: