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

From Peter Eisentraut
Subject Re: Allowing WAL fsync to be done via O_SYNC
Date
Msg-id Pine.LNX.4.30.0103152226410.826-100000@peter.localdomain
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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Allowing WAL fsync to be done via O_SYNC  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane writes:

> "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> > ... I would either
> > use fsync as default or don't deal with O_SYNC at all.
> > But if O_DSYNC is defined and O_DSYNC != O_SYNC then we should
> > use O_DSYNC by default.
>
> Hm.  We could do that reasonably painlessly as a compile-time test in
> xlog.c, but I'm not clear on how it would play out as a GUC option.
> Peter, what do you think about configuration-dependent defaults for
> GUC variables?

We have plenty of those already, but we should avoid a variable whose
specification is:

"The default is 'on' if your system defines one of the macros O_SYNC,
O_DSYNC, O_FSYNC, and if O_SYNC and O_DSYNC are distinct, otherwise the
default is 'off'."

The net result of this would be that the average user would have
absolutely no clue what the default on his machine is.

Additionally consider that maybe O_SYNC and O_DSYNC have different values
but the kernel treats them the same anyway.  We really shouldn't try to
guess that far.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Roberto Mello
Date:
Subject: Contribute to the PL/pgSQL CookBook !!
Next
From: Peter Eisentraut
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC