Thread: Winner of naming discussions: Synchronous Commit
Thank you to everyone for input on the naming of Feature "X". The clear winner of the parameter naming was synchronous_commit, which would imply we refer to the new feature as Asynchronous Commit in the release notes and general discussions. I will be now be starting to make changes throughout the patch so that this name is used for variable names, function calls and comments. After that I'll be working on docs for this feature, though they may not be available until next week, given my current schedule. The docs will include discussions of the proof of using mixed synch/asynch commits. The ideas, in chronological order, and voices in favour of them were: transaction_guarantee Idea: Simon Riggs Supporters: None deferred_commit Idea: Tom Lane Supporters: Richard Huxton synchronous_commit Idea: Greg Stark Supporters: Simon, Josh, Tom, Bruce, Florian reliable_commit Idea: Bruce Momjian Supporters: None commit_durability Idea: Simon Riggs Supporters: None confirmed_commit Idea: Greg Smith Supporters: None synchronous_commit is a clear winner. Most of the names have difficulties as to how we would refer to them when turned off: undurable commit, unconfirmed commit, unreliable commit don't work for me, nor does undeferred commit make sense for normal commits. Also, I can't see our press release saying "PostgreSQL releases Unreliable Commit". :-) -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Mon, 2007-06-25 at 10:01 +0200, Zeugswetter Andreas ADI SD wrote: > > synchronous_commit > > Idea: Greg Stark > > Supporters: Simon, Josh, Tom, Bruce, Florian > > There was one more: > asynchronous_commit > Idea: Florian G. Pflug > Supporters: none > > But if you are calling the feature that (which imho is good), the guc > might as well get that name. Hmmm, so we have a choice of: synchronous_commit = off asynchronous_commit = on For the latter, postgresql.conf would default to asynchronous_commit = off. Personally, I think the double negative is confusing for the normal case. For me, the feature is turning off something that we normally have, rather than actively initiating anything. The feature is related to fsync = off, so it would be confusing to have the switches work in opposite directions. Now I look, I see this would make it the only parameter that turning it on removes something. All other parameters are positive, e.g. enable_X = on So, although its a knife edge decision, I'd say go with synchronous_commit = off. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote: > So, although its a knife edge decision, I'd say go with > synchronous_commit = off. I agree - I'm not entirely sure why but it just feels more natural than asynchronous_commit = on. Plus the reasons you give seem valid. Regards, Dave
> synchronous_commit > Idea: Greg Stark > Supporters: Simon, Josh, Tom, Bruce, Florian There was one more: asynchronous_commit Idea: Florian G. Pflug Supporters: none But if you are calling the feature that (which imho is good), the guc might as well get that name. Andreas
On Jun 25, 2007, at 3:30 AM, Dave Page wrote: > Simon Riggs wrote: >> So, although its a knife edge decision, I'd say go with >> synchronous_commit = off. > > I agree - I'm not entirely sure why but it just feels more natural > than asynchronous_commit = on. Plus the reasons you give seem valid. On the flip-side, experienced DBAs are likely tuned into anything labeled as "asynchronous"... I'm wondering if it would be wise to throw a warning at startup if either sync_commit or fsync were set to off, ideally so that it would both appear in the logs as well as in output from pg_ctl. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim Nasby <decibel@decibel.org> writes:
> I'm wondering if it would be wise to throw a warning at startup if
> either sync_commit or fsync were set to off, ideally so that it would
> both appear in the logs as well as in output from pg_ctl.
Egad. And no doubt also complain about politically incorrect settings
of full_page_writes, add_missing_from, standard_conforming_strings, etc?
Mebbe throw a warning if listen_addresses allows any nonlocal
connections, since obviously you expose yourself to danger that way.
If you think you can get the motion to pass, propose removing these
options entirely. Don't bother us with nanny-ism.
regards, tom lane