Tom Lane escribió:
> Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> writes:
> > Tom Lane escribi� >> Hmm, maybe we need to improve the code too. This example suggests that
> >> there needs to be some limit on the worker launch rate, even if there
> >> are so many databases that that means we don't meet naptime exactly.
>
> > We already have a 100ms lower bound on the sleep time (see
> > launcher_determine_sleep()). Maybe that needs to be increased?
>
> Maybe. I hesitate to suggest a GUC variable ;-)
Heh :-)
> One thought is that I don't trust the code implementing the minimum
> too much:
>
> /* 100ms is the smallest time we'll allow the launcher to sleep */
> if (nap->tv_sec <= 0 && nap->tv_usec <= 100000)
> {
> nap->tv_sec = 0;
> nap->tv_usec = 100000; /* 100 ms */
> }
>
> What would happen if tv_sec is negative and tv_usec is say 500000?
> Maybe negative tv_sec is impossible here, but ...
I don't think it's possible to get negative tv_sec here currently, but
perhaps you're right that we could make this code more future-proof.
However I think there's a bigger problem here, which is that if the user
has set naptime too low, i.e. to a value lower than
number-of-databases * 100ms, we'll be running the (expensive)
rebuild_database_list function on each iteration ... maybe we oughta put
a lower bound on naptime based on the number of databases to avoid this
problem.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
