> 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).
>
> (Actually, you could probably eliminate the notion of "fsync request"
> entirely, and simply have each vfd get marked "dirty" automatically when
> written to. Both closing a vfd and the scan at xact commit would look
> at the dirty bit to decide to do fsync.)
>
> 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...
Glad someone is looking into this. Seems the above concern about order
is fine because it is only marking the pg_log transactions as committed
that is important. You can fsync anything you want, you just need to
make sure you current transactions buffers are fsync'ed before you mark
the transaction as complete.
-- 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