Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: > Increase it to what?
Jeff's opinion that it could be INT_MAX without causing trouble is a bit over-optimistic, see vacuum_delay_point(): if (VacuumCostActive && !InterruptPending && VacuumCostBalance >= VacuumCostLimit) { int msec; msec = VacuumCostDelay * VacuumCostBalance / VacuumCostLimit; In the first place, if VacuumCostLimit is too close to INT_MAX, it'd be possible for VacuumCostBalance (also an int) to overflow between visits to vacuum_delay_point, wrapping around to negative and thus missing the need to nap altogether. In the second place, since large VacuumCostLimit implies large VacuumCostBalance when we do get through this if-check, there's a hazard of integer overflow in the VacuumCostDelay * VacuumCostBalance multiplication. The final value of the msec calculation should be easily within integer range, since VacuumCostDelay is constrained to not be very large, but that's no help if we have intermediate overflow. Possibly we could forestall both of those problems by changing VacuumCostBalance to double, but that would make the cost bookkeeping noticeably more expensive than it used to be. I think it'd be better to keep VacuumCostBalance as int, which would then mean we'd better limit VacuumCostLimit to no more than say INT_MAX/2 --- call it 1 billion for the sake of a round number. That'd still leave us at risk of an integer overflow in the msec-to-sleep calculation, but that calculation could be changed to double at little price, since once we get here we're going to sleep awhile anyway. BTW, don't forget autovacuum_cost_limit should have the same maximum. regards, tom lane