Skip site navigation (1) Skip section navigation (2)

Re: BUG #4945: Parallel update(s) gone wild

From: "Dan Boeriu" <dan(dot)boeriu(at)roost(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>,"Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>,"PostgreSQL bugs" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4945: Parallel update(s) gone wild
Date: 2009-07-30 22:11:39
Message-ID: EF2E22898E35844BA4479BBF97078AC1FD0ABE@be10.exg4.exghost.com (view raw or flat)
Thread:
Lists: pgsql-bugs

Is there a workaround?
To us this is pretty bad news; we receive updates from several partners and constantly update the counts like in the example I sent you...
Obviously we can serialize the updates but that would be pretty sad thing to do in a database.
Realistically - when will we see this fixed (I understand it has pretty low priority...) ?

Thanks a bunch for your time,

Dan Boeriu
Senior Architect - Roost.com
P: (415) 742 8056
Roost.com - 2008 Inman Award Winner for Most Innovative New Technology




-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Thu 7/30/2009 2:34 PM
To: Dan Boeriu
Cc: Robert Haas; Craig Ringer; PostgreSQL bugs
Subject: Re: [BUGS] BUG #4945: Parallel update(s) gone wild 
 
"Dan Boeriu" <dan(dot)boeriu(at)roost(dot)com> writes:
> Attached is the reproducible test case - I was able to reproduce the problem on 32 and 64 bit 8.3.6 and 8.4.0 RedHat 5.3 kernel 2.6.18-128.1.16.el5 #1 SMP

I looked at this a bit.  It's the same issue discussed at
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php
namely, that the second update finds itself trying to update a large
number of tuples that were already updated since its snapshot was taken.
That means it has to re-verify that the updated versions of those tuples
meet its WHERE qualification.  That's done by a function EvalPlanQual
that's pretty darn inefficient for complex queries like this one.
It's essentially redoing the join (and recomputing the whole sub-SELECT)
for each row that needs to be updated.

Someday I'd like us to redesign that mechanism, but don't hold
your breath ...

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Niranjan PanditDate: 2009-07-31 03:02:57
Subject: BUG #4956: Array Construct array() returning blank result
Previous:From: Tom LaneDate: 2009-07-30 21:34:48
Subject: Re: BUG #4945: Parallel update(s) gone wild

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group