From: | "dan boeriu" <dan(dot)boeriu(at)roost(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #4945: Parallel update(s) gone wild |
Date: | 2009-07-27 21:56:57 |
Message-ID: | 200907272156.n6RLuvaM087756@wwwmaster.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged online:
Bug reference: 4945
Logged by: dan boeriu
Email address: dan(dot)boeriu(at)roost(dot)com
PostgreSQL version: 8.3.6 8.3.7 8.4
Operating system: Redhat Linux
Description: Parallel update(s) gone wild
Details:
In my update I use one table to read from (let's call it READ TABLE) and
one table to update (let's call it WRITE TABLE).
Often the updates are started almost in parallel.
When I have 2 parallel updates the first one finishes but the second sends
the cpu to 100% and in certain situations it does never finish.
What I noticed is that the second will not finish if the READ table has many
rows to be read (1 million let's say) but it finishes when the read table
has only a few 1000s of rows.
Any idea why?
BTW - I disabled the triggers on both tables.
Also I tried with autovacuum=off and no difference.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabiano | 2009-07-28 00:06:12 | BUG #4946: bug - libiconv-2.dll |
Previous Message | Tom Lane | 2009-07-27 14:36:15 | Re: BUG #4944: Problems with using \set variables as strings in select statements |