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

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

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Dan Boeriu <dan(dot)boeriu(at)roost(dot)com>, PostgreSQL bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4945: Parallel update(s) gone wild
Date: 2009-07-28 06:13:55
Message-ID: 1248761635.10632.248.camel@wallace.localnet (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Please reply to the list, not directly to me.

> I don't think is that simple. The VERY SAME statement runs twice - one
> finishes in about 20 secs the other doesn't finish in 24 hours.

Yep, OK, so it's not just a planning or scaling issue.

Have you checked pg_locks ?

  SELECT * FROM pg_locks;

What does pg_stat_activity indicate about the query?

  SELECT * FROM pg_stat_activity;

> The plan might change from one execution to the other - is there a way
> to get the executed plan at runtime?

I think there is in 8.4, but I haven't moved up to it and tested yet.
Not in previous versions.

Craig Ringer

In response to


pgsql-bugs by date

Next:From: Jim MichaelsDate: 2009-07-28 06:54:39
Subject: BUG #4947: libpq PQntuples should return 64-bit number
Previous:From: Craig RingerDate: 2009-07-28 04:23:38
Subject: Re: BUG #4945: Parallel update(s) gone wild

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