Re: COMMIT NOWAIT Performance Option

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: COMMIT NOWAIT Performance Option
Date: 2007-02-28 05:54:36
Message-ID: 4655.125.24.226.252.1172642076.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-02-28 06:02:33 Re: [HACKERS]
Previous Message Tom Lane 2007-02-28 05:44:57 Re: Packed short varlenas, what next?