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

From Craig Ringer
Subject Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch
Date
Msg-id 52EF37AF.10308@2ndquadrant.com
Whole thread Raw
In response to Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 02/01/2014 05:28 AM, Bruce Momjian wrote:
> 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.


The first patch, linked to in text, was commited as
706f9dd914c64a41e06b5fbfd62d6d6dab43eeb8.

I can't see the second in the history either. It'd be good to get it
committed, though the issue is obviously not causing any great outcry.

It was detected when testing a high-rate queueing system in PostgreSQL.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: narwhal and PGDLLIMPORT
Next
From: Amit Kapila
Date:
Subject: Re: Turning off HOT/Cleanup sometimes