"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> 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 ?
I was about to make exactly that remark. A shared buffer doesn't have
an "associated file descriptor", certainly not one that's valid across
multiple backends.
AFAICS no bookkeeping based on file descriptors (either kernel FDs
or vfds) can possibly work correctly in the multiple-backend case.
We *have to* do the bookkeeping on a relation basis, and that
potentially means (re)opening the relation's file at xact commit
in order to do an fsync. There is no value in having one backend
fsync an FD before closing the FD, because that does not take
account of what other backends may have done or do later with that
same file through their own FDs for it. If we do not do an fsync
at end of transaction, we cannot be sure that writes initiated by
*other* backends will be complete.
> There's already -F option for speeding up.
> Who would want non-WAL mode with strict reliabilty after WAL
> is implemented ?
Yes. We have a better solution in the pipeline, so ISTM it's not
worth expending a lot of effort on a stopgap.
regards, tom lane
