Tom Lane wrote:
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> >>>> BTW, I have worked a little bit on this item. The idea is pretty
> >>>> simple. Instead of doing a real fsync() in pg_fsync(), just marking it
> >>>> so that we remember to do fsync() at the commit time. Following
> >>>> patches illustrate the idea.
>
> 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...
The following is an example of what I first pointed out.
I say about PostgreSQL shared buffers not kernel buffers.
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
tableA. 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.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp