Paul Jungwirth wrote:
>> Out of curiosity: any reason the ORDER BY should be in the subquery? It
>> seems like it ought to be in
> the UPDATE (if that's allowed).
>
> Hmm, it's not allowed. :-) It's still surprising that you can guarantee the
> order of a multi-row
> UPDATE by ordering a subquer
> Out of curiosity: any reason the ORDER BY should be in the subquery? It
seems like it ought to be in the UPDATE (if that's allowed).
Hmm, it's not allowed. :-) It's still surprising that you can guarantee the
order of a multi-row UPDATE by ordering a subquery.
Paul
--
> 2) All transactions modify table rows in the same order, e.g. ascending
"id".
>With the big update you can do that by putting an "ORDER BY tg2.id"
into
>the subquery, and with the "little transactions" you'll have to make
sure
>that rows are updated in ascending "id" order.
I agree t
Alban Hertroys wrote:
> All the suggestions thus far only reduce the window in which a dead lock can
> occur.
Where do you see a window for deadlocks with my suggestions?
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscrip
On 11 March 2013 13:01, Chris Curvey wrote:
> On Sat, Mar 9, 2013 at 4:20 PM, Paul Jungwirth <
> p...@illuminatedcomputing.com> wrote:
>
>> I have a long-running multi-row UPDATE that is deadlocking with a
>> single-row UPDATE:
>>
>> 2013-03-09 11:07:51 CST ERROR: deadlock detected
>> 2013-03-09
On Sat, Mar 9, 2013 at 4:20 PM, Paul Jungwirth
wrote:
> I have a long-running multi-row UPDATE that is deadlocking with a
> single-row UPDATE:
>
> 2013-03-09 11:07:51 CST ERROR: deadlock detected
> 2013-03-09 11:07:51 CST DETAIL: Process 18851 waits for ShareLock on
> transaction 10307138; block
Paul Jungwirth wrote:
> I have a long-running multi-row UPDATE that is deadlocking with a single-row
> UPDATE:
>
> 2013-03-09 11:07:51 CST ERROR: deadlock detected
> 2013-03-09 11:07:51 CST DETAIL: Process 18851 waits for ShareLock on
> transaction 10307138; blocked by
> process 24203.
>
