> Heikki Linnakangas wrote: > On 08.02.2011 10:43, Kevin Grittner wrote: > >> I see that at least three BuildFarm critters don't have UINT64_MAX >> defined. > > I guess we'll have to just #define it ourselves. Or could we just > pick another magic value, do we actually rely on > InvalidSerCommitSeqno being higher than all other values anywhere? It seemed more robust than a low-end number, based on how it's used. >> Not sure why coypu is running out of connections. > > Hmm, it seems to choose a smaller max_connections value now, 20 > instead of 30. Looks like our shared memory usage went up by just > enough to pass that threshold. > > Looks like our shared memory footprint grew by about 2MB with > default configuration, from 37MB to 39MB. That's quite significant. > Should we dial down the default of > max_predicate_locks_per_transaction? Or tweak the sizing of the > hash tables somehow? Dialing down max_predicate_locks_per_transaction could cause the user to see "out of shared memory" errors sooner, so I'd prefer to stay away from that. Personally, I feel that max_connections is higher than it should be for machines which would have trouble with the RAM space, but I suspect I'd have trouble selling the notion that the default for that should be reduced. The multiplier of 10 PredXactList structures per connection is kind of arbitrary. It affects the point at which information is pushed to the lossy summary, so any number from 2 up will work correctly; it's a matter of performance and false positive rate. We might want to put that on a GUC and default it to something lower. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
