Re: Re: WAL and commit_delay
От | ncm@zembu.com (Nathan Myers) |
---|---|
Тема | Re: Re: WAL and commit_delay |
Дата | |
Msg-id | 20010217155314.C16600@store.zembu.com обсуждение исходный текст |
Ответ на | Re: WAL and commit_delay (Brent Verner <brent@rcfile.org>) |
Ответы |
Re: Re: WAL and commit_delay
Re: Re: WAL and commit_delay |
Список | pgsql-hackers |
On Sat, Feb 17, 2001 at 06:30:12PM -0500, Brent Verner wrote: > On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote: > > [snipped] > > | Is anyone out there running a 2.4 Linux kernel? Would you try pgbench > | with current sources, commit_delay=0, -B at least 1024, no -F, and see > | how the results change when pg_fsync is made to call fdatasync instead > | of fsync? (It's in src/backend/storage/file/fd.c) > > I've not run this requested test, but glibc-2.2 provides this bit > of code for fdatasync, so it /appears/ to me that kernel version > will not affect the test case. > > [glibc-2.2/sysdeps/generic/fdatasync.c] > > int > fdatasync (int fildes) > { > return fsync (fildes); > } In the 2.4 kernel it says (fs/buffer.c) /* this needs further work, at the moment it is identical to fsync() */ down(&inode->i_sem); err = file->f_op->fsync(file,dentry); up(&inode->i_sem); We can probably expect this to be fixed in an upcoming 2.4.x, i.e. well before 2.6. This is moot, though, if you're writing to a raw volume, which you will be if you are really serious. Then, fsync really is equivalent to fdatasync. Nathan Myers ncm@zembu.com
В списке pgsql-hackers по дате отправления: