Thomas Munro wrote: > On 27 August 2014 17:18, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Thomas Munro wrote:
> >> Yes it does, thanks Alvaro and Craig. I think the attached spec > >> reproduces the problem using that trick, ie shows NOWAIT blocking, > >> presumably in EvalPlanQualFetch (though I haven't stepped through it > >> with a debugger yet). I'm afraid I'm out of Postgres hacking cycles > >> for a few days, but next weekend I should have a new patch that fixes > >> this by teaching EvalPlanQualFetch about wait policies, with isolation > >> tests for NOWAIT and SKIP LOCKED. > > > > Hmm, http://www.postgresql.org/message-id/51fb6703.9090...@2ndquadrant.com > > Thanks, I hadn't seen this, I should have checked the archives better. > I have actually already updated my patch to handle EvalPlanQualFetch > with NOWAIT and SKIP LOCKED with isolation specs, see attached. I > will compare with Craig's and see if I screwed anything up... of > course I am happy to merge and submit a new patch on top of Craig's if > it's going to be committed. I tried Craig's patch with your test case and found that it stalls in XactLockTableWait inside EPQFetch because it doesn't throw an error in the noWait case before waiting. I think I will fix that and push, including both test cases. Then we can see about rebasing your patch. I am wondering about backpatching Craig's fix. It looks to me like it should be backpatched as far back as NOWAIT exists, but that was in 8.1 and we haven't ever gotten a complaint until Craig's report AFAIK, which I understand wasn't coming from a user finding a problem but rather some new development. So I hesitate. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers