Re: [HACKERS] TODO item

> 1. It doesn't guarantee that the right files are fsync'd.  It would
> in fact fsync whichever files happen to be using the same kernel
> file descriptor numbers at the close of the transaction as the ones
> you really wanted to fsync were using at the time fsync was requested.

Right. If a VFD is reused, the fd would not point to the same file
anymore.

> You could possibly fix #1 by logging fsync requests at the vfd level;
> then, whenever a vfd is closed to free up a kernel fd, check the fsync
> flag and execute the pending fsync before closing the file.  You could
> possibly fix #2 by having transaction commit invoke the pg_fsync_pending
> scan before it updates pg_log (and then fsyncing pg_log itself again
> after).

I do not understand #2. I call pg_fsync_pending twice in
RecordTransactionCommit, one is after FlushBufferPool, and the other
is after TansactionIdCommit and FlushBufferPool. Or am I missing
something?

> What would still need to be thought about is whether this scheme
> preserves the ordering guarantee when a group of concurrent backends
> is considered, rather than one backend in isolation.  (I believe that
> fsync() will apply to all dirty kernel buffers for a file, not just
> those dirtied by the requesting process, so each backend's fsyncs can
> affect the order in which other backends' writes hit the disk.)
> Offhand I do not see any problems there, but it's the kind of thing
> that requires more than offhand thought...

I thought about that too. If the ordering was that important, a
database managed by backends with -F on could be seriously
corrupted. I've never heard of such disasters caused by -F.  So my
conclusion was that it's safe or I had been so lucky. Note that I'm
not talking about pg_log vs. relations but the ordering among
relations.

BTW, Hiroshi has noticed me an excellent point #3:

>Session-1
>begin;
>update A ...;
>
>Session-2
>begin;
>select * fromB ..;
>    There's no PostgreSQL shared buffer available.
>    This backend has to force the flush of a free buffer
>    page. Unfortunately the page was dirtied by the
>    above operation of Session-1 and calls pg_fsync()
>    for the table A. However fsync() is postponed until
>    commit of this backend.
>
>Session-1
>commit;
>    There's no dirty buffer page for the table A.
>    So pg_fsync() isn't called for the table A.

Seems there's no easy solution for this. Maybe now is the time to give
up my idea...
--
Tatsuo Ishii