Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch
От | Craig Ringer |
---|---|
Тема | Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch |
Дата | |
Msg-id | 52EF37AF.10308@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: FOR [SHARE|UPDATE] NOWAIT may still block in EvalPlanQualFetch (Bruce Momjian <bruce@momjian.us>) |
Список | 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 по дате отправления: