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 23:11:16 |
Message-ID: | 16027.984697876@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:
> switch(lower(string[0]) + lower(string[5]))
> {
> case 'f': /* fsync */
> case 'f' + 's': /* fdatasync */
> case 'o' + 's': /* open_sync */
> case 'o' + 'd': /* open_datasync */
> }
> Although ugly, it should serve as a readable solution for now.
Ugly is the word ...
>> Do you object if I add an "assign_hook" to guc.c that's called when an
>> actual assignment is made?
> Something like this is on my wish list, but I'm not sure if it's wise to
> start this now.
I'm not particularly concerned about changing the interface later if
that proves necessary. We're not likely to have so many of the things
that an API change is burdensome, and they will all be strictly backend
internal.
What I have in mind for now is just
void (*assign_hook) (const char *newval);
(obviously this is for string variables only, for now) called just
before actually changing the variable value. This lets the hook see
the old value if it needs to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-03-15 23:13:00 | Re: Allowing WAL fsync to be done via O_SYNC |
Previous Message | Alfred Perlstein | 2001-03-15 23:02:20 | Re: Allowing WAL fsync to be done via O_SYNC |