Re: Re: WAL and commit_delay - Mailing list pgsql-hackers

From ncm@zembu.com (Nathan Myers)
Subject Re: Re: WAL and commit_delay
Date
Msg-id 20010217155314.C16600@store.zembu.com
Whole thread Raw
In response to Re: WAL and commit_delay  (Brent Verner <brent@rcfile.org>)
Responses Re: Re: WAL and commit_delay  (Brent Verner <brent@rcfile.org>)
Re: Re: WAL and commit_delay  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Microsecond sleeps with select()
Next
From: Brent Verner
Date:
Subject: Re: Re: WAL and commit_delay