On Tue, May 24, 2011 at 12:34 PM, Noah Misch <noah@leadboat.com> wrote:
> There's a potentially-unbounded delay between when the subject backend reads
> strong_lock_counts[] and when it sets its fast-path-used flag. (I didn't mean
> "not yet seen" in the sense that some memory load would not show the latest
> value. I just meant that the subject backend may still be taking relevant
> actions based on its previous load of the value.) We could have the subject
> set its fast-path-used flag before even checking strong_lock_counts[], then
> clear the flag when strong_lock_counts[] dissuaded it from proceeding. Maybe
> that's what you had in mind?
I'd like to say yes, but actually, no, I just failed to notice the
race condition. It's definitely less appealing if we have to do it
that way.
Another idea would be to only clear the fast-path-used flags lazily.
If backend A inspects the fast-path queue for backend B and finds it
completely empty, it clears the flag; otherwise it just stays set
indefinitely.
> That being said, it's a slight extra cost for all fast-path lockers to benefit
> the strong lockers, so I'm not prepared to guess whether it will pay off.
Yeah. Basically this entire idea is about trying to make life easier
for weak lockers at the expense of making it more difficult for strong
lockers. I think that's a good trade-off in general, but we might
need to wait until we have an actual implementation to judge whether
we've turned the dial too far.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company