From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Allowing WAL fsync to be done via O_SYNC |
Date: | 2001-03-15 18:15:18 |
Message-ID: | 14465.984680118@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-03-15 18:17:20 | Re: Allowing WAL fsync to be done via O_SYNC |
Previous Message | Ross J. Reedstrom | 2001-03-15 17:53:37 | Re: rtrim giving weird result |