Re: [HACKERS] TODO item

Tom Lane wrote:

> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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 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.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp