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.sm...@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
