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
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 Mon, 2007-06-25 at 10:01 +0200, Zeugswetter Andreas ADI SD wrote:
synchronous_commit
Idea: Greg Stark
Supporters: Simon, Josh, Tom, Bruce, FlorianThere was one more:
asynchronous_commit
Idea: Florian G. Pflug
Supporters: noneBut 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
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