Re: COMMIT NOWAIT Performance Option - Mailing list pgsql-hackers

From Jeroen T. Vermeulen
Subject Re: COMMIT NOWAIT Performance Option
Date
Msg-id 4655.125.24.226.252.1172642076.squirrel@webmail.xs4all.nl
Whole thread Raw
In response to Re: COMMIT NOWAIT Performance Option  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
On Wed, February 28, 2007 06:59, Jim C. Nasby wrote:
> On Tue, Feb 27, 2007 at 05:18:28PM -0500, Bruce Momjian wrote:

>> I think we will remove fsync in favor of the new delay, and allow -1 to
>> be the same behavior as fsync off.
>
> Well, presumably we'd still allow fsync for some number of versions...

I'd hate to lose the ability to disable fsync.  I run tons of tests that
don't require any protection against server crashes or hardware failures,
but their speed does matter.  I know it's not the most important
requirement in the world, but speeding up those tests means I can run more
of them, on more hardware, more often.  Test time also affects my
development cycle.

My main worry is where the option is set, though.  For my situation,
selecting a "fast and sloppy" mode when starting the server is clearly the
best choice.  It'd be possible, though awkward, to change my code to use
COMMIT NOWAIT.  But then am I really sure I'm still testing the same
thing?  Plus it introduces a risk of binaries (distributed by others)
accidentally doing COMMIT NOWAIT, as for testing, in production code.


Jeroen




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Packed short varlenas, what next?
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES]