To: Greg Smith <gsmith@gregsmith.com>
cc: James Mansion <james@mansionfamily.plus.com>,
	pgsql-performance@postgresql.org
Subject: Re: POSIX file updates 
In-reply-to: <Pine.GSO.4.64.0803311618040.15117@westnet.com> 
References: <47F1413B.40109@mansionfamily.plus.com>
	<Pine.GSO.4.64.0803311618040.15117@westnet.com>
Comments: In-reply-to Greg Smith <gsmith@gregsmith.com>
	message dated "Mon, 31 Mar 2008 18:44:27 -0400"
Date: Tue, 01 Apr 2008 01:07:17 -0400
Message-ID: <20606.1207026437@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Greg Smith <gsmith@gregsmith.com> writes:
> Quoting from Lewine's "POSIX Programmer's Guide":

> "After a write() to a regular file has successfully returned, any 
> successful read() from each byte position in the file that was modified by 
> that write() will return the data that was written by the write()...a 
> similar requirement applies to multiple write operations to the same file 
> position"

Yeah, I imagine this is what the OP is thinking of.  But note that what
it describes is the behavior of concurrent write() and read() calls
within a normally-functioning system.  I see nothing there that
constrains the order in which writes hit physical disk, nor (to put it
another way) that promises anything much about the state of the
filesystem after a crash.

As you stated, PG is largely independent of these issues anyway.  As
long as the filesystem honors its spec-required contract that it won't
claim fsync() is complete before all the referenced data is safely on
persistent store, we are OK.

			regards, tom lane