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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Alfred Perlstein <bright(at)wintelcom(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, vmikheev(at)SECTORBASE(dot)COM, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date: 2000-11-11 16:01:32
Message-ID: 23397.973958492@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hans Schou 2000-11-11 16:23:40 Danish database patent
Previous Message Tom Lane 2000-11-11 15:55:16 Re: Coping with 'C' vs 'newC' function language names