From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
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:28:13 |
Message-ID: | 15547.984691693@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> 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'."
Unfortunately, I think that's just about what the default would need to
be. What alternative do you have to offer?
> The net result of this would be that the average user would have
> absolutely no clue what the default on his machine is.
Sure he would. Fire up the software and do "SHOW wal_use_fsync"
(or whatever we call it). I think the documentation could just say
"the default is platform-dependent".
> 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.
Well, that's exactly *why* we need an overridable default. Or would you
like to try to do some performance measurements in configure?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-15 21:32:09 | Re: Allowing WAL fsync to be done via O_SYNC |
Previous Message | Mikheev, Vadim | 2001-03-15 21:28:08 | RE: Allowing WAL fsync to be done via O_SYNC |