Tom Lane wrote: > It seems that time-based GUC variables can be spelled like > 1h but not 1hr > 1min but not 1m > 1s but not 1sec > This is inconsistent and confusing. I don't object to the ones on the > left as being the standard spellings for printout, but if we're not > going to have a simple uniform rule like "shortest possible > abbreviation" then we ought to accept plausible alternatives on input. > > I got burnt by this just now because I looked at the autovacuum_naptime > setting in postgresql.conf, which is shown as '1min', and figured I > could change it to '5sec'.
Some random observations: - I was bitten by this too, not long ago, and took me a while to understand why. Should we at least log a HINT or something? - We do allow preffixes in certain cases. For example I can specify a naptime in milliseconds: $ postmaster -c autovacuum_naptime=2000ms and it shows up as "2s" in SHOW. However, preffixing with M or K does not work: $ postmaster -c autovacuum_naptime=2Ms FATAL: parameter "autovacuum_naptime" requires an integer value $ postmaster -c autovacuum_naptime=2Ks FATAL: parameter "autovacuum_naptime" requires an integer value "millihours" doesn't seem to work either. - In shared_buffers, these work: 8MB 8 MB These don't work: 8M B 8 M B 8mB 8m 8M I think this means we could safely use "m" as an abbreviation for "minutes", where it is not preffixed by anything else (so "mm" would not mean milliminutes, nor millimeters). It is not confused with meters because we don't use longitude anywhere in our configuration settings and are not likely to start doing so in the foreseeable future. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
