Re: Simplifying wal_sync_method

In summary, we added all those wal_sync_method values in hopes of
getting some data on which is best on which platform, but having gone
several years with few reports, I am thinking we should just choose the
best ones we can and move on, rather than expose a confusing API to the
users.

Does anyone show a platform where the *data* options are slower than the
non-*data* ones?

---------------------------------------------------------------------------

pgman wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Currently, here are the options available for wal_sync_method:
> > >     #wal_sync_method = fsync        # the default varies across platforms:
> > >                                     # fsync, fdatasync, fsync_writethrough,
> > >                                     # open_sync, open_datasync
> > 
> > > I don't understand why we support so many values.
> > 
> > Because there are so many platforms with different subsets of these APIs
> > and different performance characteristics for the ones they do have.
> 
> Right, and our current behavior makes it harder for people to even know
> the supported options.
> 
> > > It seems 'fsync' should be fdatasync(), and if that is not available,
> > > fsync().
> > 
> > I have yet to see anyone do any systematic testing of the different
> > options on different platforms.  In the absence of hard data, proposing
> > that we don't need some of the options is highly premature.
> 
> No one is every going to do it, so we might as well make the best guess
> we have.  I think any platform where the *data* options are slower than
> the non-*data* options is broken, and if that logic holds, we might as
> well just use *data* by default if we can, which is my proposal.
> 
> > > In fact, 8.1 uses O_DIRECT if available,
> > 
> > That's a decision that hasn't got a shred of evidence to justify
> > imposing it on every platform.
> 
> Right, and there is no evidence it hurts, so we do our best until
> someone comes up with data to suggest we are wrong.  The same should be
> done with *data*.
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073