block
device would do the trick of flushing the disk cache.
Dan
- Original Message -
From: "Andres Freund"
To: pgsql-hackers@postgresql.org
Cc: "Dan Scales"
Sent: Monday, February 27, 2012 12:43:49 PM
Subject: Re: [HACKERS] possible new option for wal_sync_method
Hi,
Hi,
On Friday, February 17, 2012 01:17:27 AM Dan Scales wrote:
> Good point, thanks. From the ext3 source code, it looks like
> ext3_sync_file() does a blkdev_issue_flush(), which issues a flush to the
> block device, whereas simple direct IO does not. So, that would make
> this wal_sync_method
n.
Dan
- Original Message -
From: "Andres Freund"
To: pgsql-hackers@postgresql.org
Cc: "Dan Scales"
Sent: Thursday, February 16, 2012 10:32:09 AM
Subject: Re: [HACKERS] possible new option for wal_sync_method
Hi,
On Thursday, February 16, 2012 06:18:23 PM Dan Scale
On 2/16/12 9:18 AM, Dan Scales wrote:
> Do folks have any interest in this change, or comments on its
> usefulness/correctness? It would be just an extra option for
> wal_sync_method that users can try out and has benefits for certain
> configurations.
Does it have any benefit on Ext4/XFS/Butrfs?
On Thu, Feb 16, 2012 at 19:18, Dan Scales wrote:
> fsync/fdatasync can be very slow on ext3, because it seems to have to
> always wait for the current filesystem meta-data transaction to complete,
> even if that meta-data operation is completely unrelated to the file
> being fsync'ed.
Use the dat
Hi,
On Thursday, February 16, 2012 06:18:23 PM Dan Scales wrote:
> When running Postgres on a single ext3 filesystem on Linux, we find that
> the attached simple patch gives significant performance benefit (7-8% in
> numbers below). The patch adds a new option for wal_sync_method, which
> is "ope
