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

From Tom Lane
Subject Re: Allowing WAL fsync to be done via O_SYNC
Date
Msg-id 14465.984680118@sss.pgh.pa.us
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  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Allowing WAL fsync to be done via O_SYNC  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> As a general rule, if something can be a run time option, as opposed to a
> compile time option, then it should be.  At the very least you keep the
> installation simple and allow for easier experimenting.

I've been mentally working through the code, and see only one reason why
it might be necessary to go with a compile-time choice: suppose we see
that none of O_DSYNC, O_SYNC, O_FSYNC, [others] are defined?  With the
compile-time choice it's easy: #define USE_FSYNC_FOR_WAL, and sail on.
If it's a GUC variable then we need a way to prevent the GUC option from
becoming unset (which would disable the fsync() calls, leaving nothing
to replace 'em).  Doable, perhaps, but seems kind of ugly ... any
thoughts about that?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Next
From: Tom Lane
Date:
Subject: Re: rtrim giving weird result