Re: Allowing WAL fsync to be done via O_SYNC - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: Allowing WAL fsync to be done via O_SYNC
Date
Msg-id 20010315114013.A29888@fw.wintelcom.net
Whole thread Raw
In response to Re: Allowing WAL fsync to be done via O_SYNC  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Allowing WAL fsync to be done via O_SYNC  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Peter Eisentraut <peter_e@gmx.net> [010315 11:33] wrote:
> Alfred Perlstein writes:
> 
> > Sorry, what's a GUC? :)
> 
> Grand Unified Configuration system
> 
> It's basically a cute name for the achievement that there's now a single
> name space and interface for (almost) all postmaster run time
> configuration variables,

Oh, thanks.

Well considering that, a runtime check for doing_sync_wal_writes
== 1 shouldn't be that expensive.  Sort of the inverse of -F,
meaning that we're using O_SYNC for WAL writes, we don't need to
fsync it.

Btw, if you guys want to get some speed with WAL, I'd implement a
write-behind process if it was possible to do the O_SYNC writes.

...

And since we're sorta on the topic of IO, I noticed that it looks
like (at least in 7.0.3) that vacuum and certain other routines
read files in reverse order.

The problem (at least in FreeBSD) is that we haven't tuned
the system to detect reverse reading and hence don't do
much readahead.  There may be some going on as a function
of the read clustering, but I'm not entirely sure.

I'd suspect that other OSs might have neglected to check
for reverse reading of files as well, but I'm not sure.

Basically, if there was a way to do this another way, or
anticipate the backwards motion and do large reads, it
may add latency, but it should improve performance.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]



pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Next
From: Tom Lane
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC