Re: Re: WAL and commit_delay

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: WAL and commit_delay
Date: 2001-02-17 23:53:14
Message-ID: 20010217155314.C16600@store.zembu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)zembu(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brent Verner 2001-02-18 00:10:09 Re: Re: WAL and commit_delay
Previous Message Nathan Myers 2001-02-17 23:35:15 Re: Microsecond sleeps with select()