Re: AW: [HACKERS] fsynch of pg_log write..

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Zeugswetter Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: AW: [HACKERS] fsynch of pg_log write..
Date: 1999-06-25 15:37:03
Message-ID: 199906251537.LAA25338@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > > committed". The problem is when a client is told something,
> > > that is not true after a crash, which can happen if the second
> > > flush is left out.
> >
> > But commercial db's do that. They return 'done' for every query, while
> > they write they log files ever X seconds. We need to allow this. No
> > reason to be more reliable than commercial db's by default. Or, at
> > least we need to give them the option because the speed advantage is
> > huge.
> >
> I agree, but commercial db's don't do that.
> Oracle does not (only on Linux).
> Informix only does it when you specially create the database
> (create database dada with buffered log;) I always use it :-)
> Informix has a log buffer, which is flushed at transaction commit
> (unbuffered logging) or when the buffer is full (buffered logging).
> None of them do any "every X seconds stuff".

Yes! All my clients use Informix buffered logging. Now, these are law
firms running their billing systems using Informix. The 'buffer full'
write is kind of limited in that it does not give a good time limit on
vulnerability. It has to do this because it wants to write a full tape
block. Newer versions worked around this with some kind of intermediate
fix(not sure). Anyway, having a time limit in the fsync will give us
goo performance with a reliable/limited exposure to risk.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hub.Org News Admin 1999-06-25 17:31:53
Previous Message Chris Bitmead 1999-06-25 14:58:20 Severe SUBSELECT bug in 6.5 CVS