Re: Allowing WAL fsync to be done via O_SYNC

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Date: 2001-03-15 21:33:44
Message-ID: Pine.LNX.4.30.0103152226410.826-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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(at)gmx(dot)net http://yi.org/peter-e/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-03-15 21:37:57 Re: Allowing WAL fsync to be done via O_SYNC
Previous Message Tom Lane 2001-03-15 21:32:09 Re: Allowing WAL fsync to be done via O_SYNC