Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch
Date
Msg-id 20140131212808.GR19957@momjian.us
Whole thread Raw
In response to FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch  (Craig Ringer <craig@2ndquadrant.com>)
Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Fri, Aug  2, 2013 at 04:00:03PM +0800, Craig Ringer wrote:
> FOR SHARE|UPDATE NOWAIT will still block if they have to follow a ctid
> chain because the call to EvalPlanQualFetch doesn't take a param for
> noWait, so it doesn't know not to block if the updated row can't be locked.
> 
> The attached patch against master includes an isolationtester spec to
> demonstrate this issue and a proposed fix. Builds with the fix applied
> pass "make check" and isolationtester "make installcheck".
> 
> To reach this point you need to apply the patch in
> http://www.postgresql.org/message-id/51FB4305.3070600@2ndquadrant.com
> first, otherwise you'll get stuck there and won't touch the code changed
> in this patch.

The above looks like a legitimate patch that was not applied:
http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com

The patch mentioned in the text above was applied, I think.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary
Next
From: Bruce Momjian
Date:
Subject: Re: FOR UPDATE/SHARE incompatibility with GROUP BY, DISTINCT, HAVING and window functions