Message-ID: <4B6E8682.7030006@2ndquadrant.com>
Date: Sun, 07 Feb 2010 04:23:14 -0500
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Andres Freund <andres@anarazel.de>, Greg Stark <gsstark@mit.edu>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org,
	Michael Clemmons <glassresistor@gmail.com>,
	Hannu Krosing <hannu@2ndquadrant.com>,
	Scott Marlowe <scott.marlowe@gmail.com>
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1
	ubuntu karmic slow createdb)
References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com>	
	<4B698605.50506@anarazel.de> <4B6CF822.9010608@2ndquadrant.com>	
	<201002061304.01682.andres@anarazel.de>
	<603c8f071002062113k262dd8xcd0cdd482d2c6150@mail.gmail.com>
In-Reply-To: <603c8f071002062113k262dd8xcd0cdd482d2c6150@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Robert Haas wrote:
> Well it seems that what we're trying to implement is more like
> it_would_be_nice_if_you_would_start_syncing_this_file_range_but_its_ok_if_you_dont(),
> so maybe that would work.
>
> Anyway, is there something that we can agree on and get committed here
> for 9.0, or should we postpone this to 9.1?  It seems simple enough
> that we ought to be able to get it done, but we're running out of time
> and we don't seem to have a clear vision here yet...
>   

This is turning into yet another one of those situations where something 
simple and useful is being killed by trying to generalize it way more 
than it needs to be, given its current goals and its lack of external 
interfaces.  There's no catversion bump or API breakage to hinder future 
refactoring if this isn't optimally designed internally from day one.

The feature is valuable and there seems at least one spot where it may 
be resolving the possibility of a subtle OS interaction bug by being 
more thorough in the way that it writes and syncs.  The main contention 
seems to be over naming and completely optional additional abstraction.  
I consider the whole "let's make this cover every type of complicated 
sync on every platform" goal interesting and worthwhile, but it's 
completely optional for this release.  The stuff being fretted over now 
is ultimately an internal interface that can be refactored at will in 
later releases with no user impact.

If the goal here could be shifted back to finding the minimal level of 
abstraction that doesn't seem completely wrong, then updating the 
function names and comments to match that more closely, this could 
return to committable.  That's all I thought was left to do when I moved 
it to "ready for committer", and as far as I've seen this expanded scope 
of discussion has just moved backwards from that point.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com