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