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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements
Дата
Msg-id 16828058-9215-1a87-2e8a-16df381a8154@aklaver.com
обсуждение исходный текст
Ответ на Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements  (trafdev <trafdev@mail.ru>)
Список pgsql-general
On 07/02/2016 09:01 PM, trafdev wrote:
> 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?

My little voice says the below is the answer:

https://www.postgresql.org/docs/9.5/static/sql-select.html#SQL-FOR-UPDATE-SHARE

I just do not have enough coffee in me yet to apply it your situation
directly.

>
>> 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.
>


--
Adrian Klaver
adrian.klaver@aklaver.com


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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: 9.3 to 9.5 upgrade problems
Следующее
От: Mark Morgan Lloyd
Дата:
Сообщение: Re: Stored procedure version control