RE: [HACKERS] TODO item

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)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(at)tpf(dot)co(dot)jp