On Fri, Jul 22, 2011 at 3:28 PM, Noah Misch <n...@2ndquadrant.com> wrote: > On Thu, Jul 21, 2011 at 11:37:27PM -0400, Robert Haas wrote: >> I think I have a simpler idea, though: >> before acquiring any locks, just have SIGetDataEntries() do this: >> >> + if (stateP->nextMsgNum == segP->maxMsgNum && !stateP->resetState) >> + return 0; >> >> Patch (with comment explaining why I think this is OK) attached. If >> the message numbers happen to be equal only because the counter has >> wrapped, then stateP->resetState will be true, so we'll still realize >> we need to do some work. > > This is attractive, and I don't see any problems with it. (In theory, you > could > hit a case where the load of resetState gives an ancient "false" just as the > counters wrap to match. Given that the wrap interval is 1000000x as long as > the > reset interval, I'm not worried about problems on actual silicon.)
It's actually 262,144 times as long - see MSGNUMWRAPAROUND. It would be pretty easy to eliminate even the theoretical possibility of a race by getting rid of resetState altogether and using nextMsgNum = -1 to mean that. Maybe I should go ahead and do that. > +1 for doing this and moving on. Yeah, I think I'll go ahead and commit something along these lines if no one objects. We can always fine-tune it more if needed (but it probably isn't). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
