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
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 |