On Wed, Jul 27, 2011 at 01:30:47PM -0400, Robert Haas wrote: > On Wed, Jul 27, 2011 at 12:55 PM, Noah Misch <n...@2ndquadrant.com> wrote: > > [wrong objection] > > Eh, how can this possibly happen? You have to hold msgNumLock to to > set maxMsgNum and msgNumLock to read maxMsgNum. If that's not enough > to guarantee that we never read a stale value, what is?
Indeed, my analysis was all wrong. > > I think a benchmark is in order, something like 900 idle connections and 80 > > connections running small transactions that create a few temporary tables. > > If > > that shows no statistically significant regression, then we're probably fine > > here. I'm not sure what result to expect, honestly. > > That's setting the bar pretty high. I don't mind doing the > experiment, but I'm not sure that's the case we should be optimizing > for. Granted. How about 32 clients running the temporary table transaction, no idle connections? Given the meager benefit of this patch compared to your previous version, it would be hard to justify a notable performance drop in return. > > What did you think of making the message number a uint64, removing > > wraparound > > handling, and retaining SISeg.msgnumLock for 32-bit only? You could > > isolate the > > variant logic in READ_MSGNUM and WRITE_MSGNUM macros. > > Well, what you really need to know is whether the platform has 8-byte > atomic stores, which doesn't seem trivial to figure out, plus you need > a memory fence. If that's the only method of fixing this problem we > can agree on, I'm willing to work on it, but an > architecture-independent fix would be nicer. Fair enough. Thanks, nm -- Noah Misch 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
