Re: foreign key locks - EvalPlanQual interactions
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-11-29T19:25:59Z
Lists: pgsql-hackers
On 2012-11-27 12:07:34 -0300, Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Here's version 24. > > Old review emails still contains some items that didn't lead to any > changes. I tried to keep close track of those. To that list I add a > couple of things of my own. Here they are, for those following along. > I welcome suggestions. > > - EvalPlanQual and ExecLockRows maybe need a different overall locking > strategy. Right now follow_updates=false is used to avoid deadlocks. I think this really might need some work. Afaics the EPQ code now needs to actually determine what locklevel needs to be passed to EvalPlanQualFetch via EvalPlanQual otherwise some of the locking issues that triggered all this remain. That sucks a bit from a modularity perspective, but I don't see another way. Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix memory leaks in record_out() and record_send().
- 273986bf0d39 9.3.0 cited