From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "Tatsuo Ishii" <t-ishii(at)sra(dot)co(dot)jp> |
Subject: | RE: [HACKERS] TODO item |
Date: | 2000-02-10 00:32:22 |
Message-ID: | 000601bf735e$4bdda440$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: owner-pgsql-hackers(at)postgresql(dot)org
> [mailto:owner-pgsql-hackers(at)postgresql(dot)org]On Behalf Of Tom Lane
>
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 2000-02-10 00:44:03 | Re: [HACKERS] backend startup |
Previous Message | Rini Dutta | 2000-02-10 00:09:22 | how to make libpq on winnt using the 'win32.mak's |