Re: COMMIT NOWAIT Performance Option

Поиск
Список
Период
Сортировка
От Jeroen T. Vermeulen
Тема Re: COMMIT NOWAIT Performance Option
Дата
Msg-id 4655.125.24.226.252.1172642076.squirrel@webmail.xs4all.nl
обсуждение исходный текст
Ответ на Re: COMMIT NOWAIT Performance Option  ("Jim C. Nasby" <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Packed short varlenas, what next?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES]