Re: Allowing WAL fsync to be done via O_SYNC
От | Peter Eisentraut |
---|---|
Тема | Re: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | Pine.LNX.4.30.0103152356440.826-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Allowing WAL fsync to be done via O_SYNC (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Allowing WAL fsync to be done via O_SYNC
|
Список | pgsql-hackers |
Tom Lane writes: > wal_sync_method = fsync | fdatasync | open_sync | open_datasync > A small problem is that I don't want to be doing multiple strcasecmp's > to figure out what to do in xlog.c. This should be efficient: 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. > 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. There are a few issues that need some thought, like how to make the interface for non-string options, and how to keep it in sync with the parse hook of string options, ... > That would provide a place to set up the flag variables that xlog.c > would actually look at. Furthermore, having an assign_hook would let > us support changing this value at SIGHUP, not only at postmaster > start. (The assign hook would just need to fsync whatever WAL file is > currently open and possibly close/reopen the file, to ensure that no > blocks miss getting synced when we change conventions.) ... and possibly here you need to pass the context to the assign hook as well. This application strikes me as a bit too esoteric for a first try. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: