Re: Maximum transaction rate

From: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
To: Marco Colombo <pgsql(at)esiway(dot)net>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Maximum transaction rate
Date: 2009-03-18 16:33:05
Message-ID: 49C12241.6050400@cheapcomplexdevices.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Marco Colombo wrote:
> Ron Mayer wrote:
>> Greg Smith wrote:
>>> There are some known limitations to Linux fsync that I remain somewhat
>>> concerned about, independantly of LVM, like "ext3 fsync() only does a
>>> journal commit when the inode has changed" (see
>>> http://kerneltrap.org/mailarchive/linux-kernel/2008/2/26/990504 )....
>> I wonder if there should be an optional fsync mode
>> in postgres should turn fsync() into
>> fchmod (fd, 0644); fchmod (fd, 0664);
'course I meant: "fchmod (fd, 0644); fchmod (fd, 0664); fsync(fd);"
>> to work around this issue.
>
> Question is... why do you care if the journal is not flushed on fsync?
> Only the file data blocks need to be, if the inode is unchanged.

You don't - but ext3 fsync won't even push the file data blocks
through a disk cache unless the inode was changed.

The point is that ext3 only does the "write barrier" processing
that issues the FLUSH CACHE (IDE) or SYNCHRONIZE CACHE (SCSI)
commands on inode changes, not data changes. And with no FLUSH
CACHE or SYNCHRONINZE IDE the data blocks may sit in the disks
cache after the fsync() as well.

PS: not sure if this is still true - last time I tested it
was nov 2006.

Ron

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pedro Doria Meunier 2009-03-18 16:46:16 Re: Accent insensitive search?
Previous Message cifroes 2009-03-18 16:29:24 Accent insensitive search?