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  (Brent Verner <brent@rcfile.org>)
Re: Re: WAL and commit_delay  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: Microsecond sleeps with select()
Следующее
От: Brent Verner
Дата:
Сообщение: Re: Re: WAL and commit_delay