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

From Bruce Momjian
Subject Re: Allowing WAL fsync to be done via O_SYNC
Date
Msg-id 200103152046.PAA18820@candle.pha.pa.us
Whole thread Raw
In response to Re: Allowing WAL fsync to be done via O_SYNC  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Allowing WAL fsync to be done via O_SYNC  (Larry Rosenman <ler@lerctr.org>)
List pgsql-hackers
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I later read Vadim's comment that fsync() of two blocks may be faster
> > than two O_* writes, so I am now confused about the proper solution. 
> > However, I think we need to pick one and make it invisible to the user. 
> > Perhaps a compiler/config.h flag for testing would be a good solution.
> 
> 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 I think it should be configurable at *some* level.  I don't much care
> whether it's a config.h entry or a GUC variable.
> 
> But consider this: we'll be more likely to get some feedback from the
> field (allowing us to refine the policy in future releases) if it is a
> GUC variable.  Not many people will build two versions of the software,
> but people might take the trouble to play with a run-time configuration
> setting.

Yes, I can imagine.  Can we remove it once we know the answer?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

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