Re: proposal: rounding up time value less than its unit.

On 9/23/14, 10:52 PM, David Johnston wrote:
> ​Given the following why not just pick "ms" for log_rotation_age now?

Right now there are people out there who have configurations that look 
like this:

log_rotation_age=60

In order to get hourly rotation.  These users will suffer some trauma 
should they upgrade to a version where this parameter now means a new 
log file pops every 60 seconds instead.  If they didn't catch the 
warning in the release notes and it happens, I'm pretty comfortable 
they'll survive though, just with a bunch of cursing until it's 
resolved.  I'd even wager a beer that more than 10% of PostgreSQL 
installs that get hit won't even notice.

I'd prefer not to make that experience into one where they get a log 
file every 60ms though.  That's seriously bad.  I'm not opposed to 
making major changes like that, I just like them to be as part of 
updates big enough that people are unlikely to miss that something is 
different.  Just doing this log_rotation_age thing is small enough that 
I expect people to miss the change in the release notes.  That limits 
how much I think we can change the magnitude of an easy to miss setting 
with a large unit adjustment.

> ? are there any special considerations for people using pg_dump vs. 
> those using pg_upgrade?​

I don't know that there's any code in pg_upgrade aiming at this sort of 
job.  I'd prefer not to add "find parameters that have changed in 
meaning and flag them" to pg_upgrade's job requirements.  It has enough 
problems to worry about, and we really don't do this very often.

> If we are going to go that far why not simply modify the GUC input 
> routine to require unit-values on these particular parameters?  Direct 
> manipulation of pg_settings probably would need some attention but 
> everything else could reject integers and non-unit-specifying text.

That would be fine by me as a long-term direction, but it's more of a 
two to three version release level of change.  To keep that from being 
terrible for users, we'd need to provide a transition release that 
helped people find the problem ones without units.  After that was in 
the wild for a while, then could we have some confidence that enough 
people had flushed the issue out enough to turn it into a hard requirement.

The project went through this exact sort of exercise with the 
standard_conforming_strings GUC being the way we flagged the bad 
constructs for people.  That was a much harder job because it touched 
everyone's application code too.  But it took many years to play out.  
I'd be shocked if we could herd our flock of old time users fast enough 
to remove unitless GUC values from PostgreSQL in less than 3 years worth 
of new releases.

-- 
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/