Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Дата
Msg-id 23397.973958492@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Not really, I thought an ack on a commit would mean that the data
>> is actually in stable storage, breaking that would be pretty bad
>> no?

> The default is to sync on commit, but we need to give people options of
> several seconds delay for performance reasons.  Inforimx calls it
> buffered logging, and it is used by most of the sites I know because it
> has much better performance that sync on commit.

I have to agree with Alfred here: this does not sound like a feature,
it sounds like a horrid hack.  You're giving up *all* consistency
guarantees for a performance gain that is really going to be pretty
minimal in the WAL context.

Earlier, Vadim was talking about arranging to share fsyncs of the WAL
log file across transactions (after writing your commit record to the
log, sleep a few milliseconds to see if anyone else fsyncs before you
do; if not, issue the fsync yourself).  That would offer less-than-
one-fsync-per-transaction performance without giving up any guarantees.
If people feel a compulsion to have a tunable parameter, let 'em tune
the length of the pre-fsync sleep ...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Coping with 'C' vs 'newC' function language names
Следующее
От: Hans Schou
Дата:
Сообщение: Danish database patent