RE: [HACKERS] TODO item

> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian
> 
> > > So, I think we are safe if we can either keep that file 
> descriptor open
> > > until commit, or re-open it and fsync it on commit.  That assume a
> > > re-open is hitting the same file.  My opinion is that we should just
> > > fsync it on close and not worry about a reopen.
> > 
> > There's still the problem that your backend might never have opened the
> > relation file at all, still less done a write through its fd or vfd.
> > I think we would need to have a separate data structure saying "these
> > relations were dirtied in the current xact" that is not tied to fd's or
> > vfd's.  Maybe the relcache would be a good place to keep such a flag.
> > 
> > Transaction commit would look like:
> > 
> > * scan buffer cache for dirty buffers, fwrite each one that belongs
> > to one of the relations I'm trying to commit;
> > 
> > * 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?

I don't object to you strongly but I ask again. 

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

Hiroshi Inoue
Inoue@tpf.co.jp