> I have not had a chance yet to browse the postgres code, some silliness about
> my day job keeps interfering, so it may be a few weeks before I get to this.
> 
> My thought is that comitting transactions can't release locks until the log
> is written. So, if the log is not flushed except every so often, locks are
> held longer harming concurrancy.
> 
> Of course, I am probably thinking about "normal" WAL type transactions not
> the "unique" postgres log thing which truth to tell I may never have
> really understood.

You have good point here.  We are telling an application that the
transaction is committed, even though if there is a crash in the next 10
seconds, on reboot, it will show it as not committed.

It is my understanding that all buffered logging database systems have
this problem, so I think we will just have to live with it.  I believe
we will still continue to offer the original fsync() after commit
behavior.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Sat, 14 Mar 1998 12:15:46 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: [QUESTIONS] Does Storage Manager support >2GB
	tables?