Re: [HACKERS] TODO item

> > > * open and fsync each segment of each rel that I'm trying to commit
> > > (or maybe just the dirtied segments, if we want to do the bookkeeping
> > > at that level of detail);
> > 
> > By fsync'ing on close, we can not worry about file descriptors that were
> > forced out of the file descriptor cache during the transaction.
> > 
> > If we dirty a buffer, we have to mark the buffer as dirty, and the file
> > descriptor associated with that buffer needing fsync.  If someone else
> 
> What is the file descriptors associated with buffers ?
> Would you call heap_open() etc each time when a buffer is about 
> to be dirtied?

WriteBuffer -> FlushBuffer to flush buffer.  Buffer can be either marked
dirty or written/fsync to disk.

If written/fsync, smgr_flush -> mdflush -> _mdfd_getseg gets MdfdVec
structure of file descriptor.  

When doing flush here, mark MdfdVec structure new element needs_fsync to
true.  Don't do fsync yet.

If just marked dirty, also mark MdfdVec.needs_fsync as true.

Do we currently all write dirty buffers on transaction commit?  We
certainly must already do that in fsync mode.

On commit, run through virtial file descriptor table and do fsyncs on
file descriptors.  No need to find the buffers attached to file
descriptors.  They have already been written by other code.  They just
need fsync.


> There's already -F option for speeding up.
> Who would want non-WAL mode with strict reliabilty after WAL
> is implemented ?

Let's see what Vadim says.  Seems like a nice performance boost and 7.0
could be 6 months away.  If we didn't ship with fsync enabled, I
wouldn't care.  Also, Vadim has a new job, so we really can't be sure
about WAL in 7.1.

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