Re: [HACKERS] TODO item

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