Date: Tue, 11 Nov 2008 10:07:53 -0500
From: Aidan Van Dyk <aidan@highrise.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Create and drop temp table in 8.3.4
Message-ID: <20081111150753.GA31053@yugib.highrise.ca>
References: <1225999071.1204.14.camel@jd-laptop.pragmaticzealot.org>
	<4912F29E.EE98.0025.0@wicourts.gov>
	<a1ec7d000811061305n7b28800od469c1411e1a9928@mail.gmail.com>
	<dcc563d10811061405l76cb59adh58741b227fe9d8a6@mail.gmail.com>
	<49131C67.EE98.0025.0@wicourts.gov>
	<dcc563d10811061445h32c5ad72o84f367d7cc3c6899@mail.gmail.com>
	<49132383.EE98.0025.0@wicourts.gov>
	<dcc563d10811061603t574c74afj4f651c4ec7dbb88d@mail.gmail.com>
	<72dbd3150811061821ub30ec93x4da25b82060e5d29@mail.gmail.com>
	<20081107031921.GE15954@yugib.highrise.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO"
Content-Disposition: inline
In-Reply-To: <20081107031921.GE15954@yugib.highrise.ca>
User-Agent: Mutt/1.5.18 (2008-05-17)


--M9NhX3UHpAaciwkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Seems like this didn't make it through to the list the first time...

* Aidan Van Dyk <aidan@highrise.ca> [081106 22:19]:
> * David Rees <drees76@gmail.com> [081106 21:22]:
>  
> > 2. A write barrier instructs the lower level hardware that commands
> > issued before the barrier must be written to disk before commands
> > issued after the barrier. Write barriers are used to ensure that data
> > written to disk is written in such a way as to maintain filesystem
> > consistency, without losing all the benefits of a write cache.
> > 
> > 3. A fsync call forces data to be synced to the controller.
> > 
> > This means that whenever you call fsync, at the very minimum, the data
> > will have made it to the controller. How much further down the line
> > will depend on whether or not the controller is in WriteBack or
> > WriteThrough mode and whether or not the disk is also caching writes.
> > 
> > So in your example, if the OS is caching some writes and fsync is
> > called, it won't be returned until at a minimum the controller has
> > accepted all the data, regardless of whether or not write barriers are
> > enabled.
> > 
> > In theory, it should be safe to disable write barriers if you have a
> > BBU because the BBU should guarantee that all writes will eventually
> > make it to disk (or at least reduce the risk of that not happening to
> > an acceptable level).
> 
> All that's "correct", but note that fsync doesn't guarentee *coherent*
> filesystem state has been made to controller.  And fsync *can* carry "later"
> writes to the controller.
> 
> I belive the particular case the prompted the write-barriers to become default
> was ext3 + journals, where in certain (rare) cases, upon recovery, things were
> out of sync.  What was happening was that ext3 was syncing the journal, but
> "extra" writes were getting carried to the controller during the sync
> operation, and if something crashed at the right time, "new" data was on the
> disk where the "old journal" (because the new journal hadn't finished making
> it to the controller) didn't expect it.
> 
> The write barriers give the FS the symantics to say "all previous queue
> writes" [BARRIER] flush to controller [BARRIER] "any new writes", and thus
> guarentee the ordering of certian operations to disk, and guarentee coherency
> of the FS at all times.
> 
> Of course, that guarenteed FS consistency comes at a cost.  As to it's
> necessity with the way PG uses the FS w/ WAL....  or it's necessity with
> xfs...
> 
> a.
> 
> -- 
> Aidan Van Dyk                                             Create like a god,
> aidan@highrise.ca                                       command like a king,
> http://www.highrise.ca/                                   work like a slave.


-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

--M9NhX3UHpAaciwkO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJGZ/IuVxNPsxNPScRApZXAJ4/dhRg1GPWntt95kgRc7ICyEq1zQCfZkg1
V6+GlrcWjAouNh/cpJ5C83A=
=33Pv
-----END PGP SIGNATURE-----

--M9NhX3UHpAaciwkO--