Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance

I wonder if kernel can sometimes provide weaker version of fsync() which 
is not enforcing all pending data to be written immediately but just 
servers as write barrier, guaranteeing
that all write operations preceding fsync() will be completed before any 
of subsequent operations.

It will allow implementation of weaker transaction models which are not 
satisfying all ACID requirements (results of committed transaction can 
be lost in case power failure or OS crash) but still preserving database 
consistency. It is acceptable for many applications and can provide much 
better performance.

Right now it is possible to implement something like this at application 
level using asynchronous write process. So all write/sync operations 
should be redirected to this process.
But such process can become a bottleneck reducing scalability of the 
system. Also communication channels with this process can cause 
significant memory/CPU overhead.

In most DBMSes including PostgreSQL transaction log and database data 
are located in separate files. So such write barrier should be 
associated not with one file, but with set of files or may be the whole 
file system.  I wonder if there are some principle problems in 
implementing or using such file system write barrier?