From: | trafdev <trafdev(at)mail(dot)ru> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements |
Date: | 2016-07-03 01:18:35 |
Message-ID: | f4b1ce48-94fa-d3fd-0d5d-37870c786698@mail.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Best guess you are running into what is described here:
>
> https://www.postgresql.org/docs/9.5/static/explicit-locking.html#LOCKING-DEADLOCKS
>
>
> Both transactions are holding locks on rows in T1 that the other wants
> also.
>
> I may be missing something, but I am not sure why it is necessary to run
> both sessions concurrently? Could you not do session1 and once it
> completes then session2?
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.
From | Date | Subject | |
---|---|---|---|
Next Message | trafdev | 2016-07-03 04:01:29 | Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements |
Previous Message | Adrian Klaver | 2016-07-02 19:45:41 | Re: deadlock between "WITH agg_tmp AS ({sel_stmt}), upd AS ({upd_stmt}) {ins_stmt}" and pure UPDATE statements |