From: | Alfred Perlstein <bright(at)wintelcom(dot)net> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Allowing WAL fsync to be done via O_SYNC |
Date: | 2001-03-15 22:51:00 |
Message-ID: | 20010315145100.E29888@fw.wintelcom.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Mikheev, Vadim <vmikheev(at)SECTORBASE(dot)COM> [010315 13:52] wrote:
> > I believe that we don't know enough yet to nail down a hard-wired
> > decision. Vadim's idea of preferring O_DSYNC if it appears to be
> > different from O_SYNC is a good first cut, but I think we'd
> > better make it possible to override that, at least for testing purposes.
>
> So let's leave fsync as default and add option to open log files
> with O_DSYNC/O_SYNC.
I have a weird and untested suggestion:
How many files need to be fsync'd?
If it's more than one, what might work is using mmap() to map the
files in adjacent areas, then calling msync() on the entire range,
this would allow you to batch fsync the data.
The only problem is that I'm not sure:
1) how portable msync() is.
2) if msync garauntees metadata consistancy.
Another benifit of mmap() is the 'zero' copy nature of it.
--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-15 22:54:22 | Re: Allowing WAL fsync to be done via O_SYNC |
Previous Message | Roberto Mello | 2001-03-15 22:45:06 | Contribute to the PL/pgSQL CookBook !! |