Tom Lane wrote: > Bruce Momjian <firstname.lastname@example.org> writes: > > ITAGAKI Takahiro wrote: > >> Bruce Momjian <email@example.com> wrote: > >>> I looked this over and I am unsure what this does for us that isn't > >>> already accomplished using the wal_sync_method settings. See xlog.c for > >>> a description of O_DIRECT and when it is used. > >> > >> I proposed it to supplement the cache control. There are some OSes that > >> supports posix_fadvise but not O_DIRECT, for example, NetBSD 4.0 > >> (http://www.netbsd.org/Changes/changes-4.0.html). > > > Oh, that makes sense then. Let me re-add it to the queue. > > Could we see some performance measurements *from those OSes*? The given > test on Linux certainly does not justify adding another operating > system dependency to the WAL code. For that matter, even if it is a big > win on some versions of NetBSD, I'm not sure I'd want to accept it ... > how many NetBSD users do we have who would care? > > Depending on OS features we have never depended on before is a *huge* > ongoing maintenance cost, and I have not seen an argument that I think > justifies this one.
I disagree. It is a localized change and seems like a win, and it uses a standard POSIX feature, rather than an OS-specific one. I fact the patch cleans up our code by centralizing the WAL close() code and error message. -- Bruce Momjian | http://candle.pha.pa.us firstname.lastname@example.org | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match