RE: [HACKERS] TODO item - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] TODO item
Date
Msg-id 000601bf735e$4bdda440$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] TODO item  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgresql.org
> [mailto:owner-pgsql-hackers@postgresql.org]On Behalf Of Tom Lane
> 
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > [ use a global sync instead of fsync ]
> 
> > 1. Does sync really wait for the completion of data be written on to
> > disk?
> 
> Linux is *alone* among Unix platforms in waiting; every other
> implementation of sync() returns as soon as the last dirty buffer
> is scheduled to be written.
> 
> > 2. Are we suffered any performance penalty from sync?
> 
> A global sync at the completion of every xact would be disastrous for
> the performance of anything else on the system.
> 
> > However, in most cases the system is dedicated for only PostgreSQL,
> 
> "Most cases"?  Do you have any evidence for that?
>

Tatsuo is afraid of the delay of WAL
OTOH,it's not so easy to solve this item in current spec.
Probably he wants a quick and simple solution.

His solution is only for limited OS but is very simple.
Moreover it would make FlushBufferPool() more reliable(
I don't understand why FlushBufferPool() is allowed to not
call fsync() per page.).

The implementation would be in time for 7.0.
Is a temporary option unitl WAL bad ? 

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


pgsql-hackers by date:

Previous
From: Rini Dutta
Date:
Subject: how to make libpq on winnt using the 'win32.mak's
Next
From: Chris Bitmead
Date:
Subject: Re: [HACKERS] backend startup