X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 41F4DD9E79
	for <pgsql-docs-postgresql.org@localhost.postgresql.org>;
	Mon,  3 Oct 2005 14:45:07 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 76836-09
	for <pgsql-docs-postgresql.org@localhost.postgresql.org>;
	Mon,  3 Oct 2005 17:45:04 +0000 (GMT)
Received: from Herge.rcsinc.local (unknown [70.89.208.142])
	by svr1.postgresql.org (Postfix) with ESMTP id 517F6D9E73
	for <pgsql-docs@postgresql.org>; Mon,  3 Oct 2005 14:45:03 -0300 (ADT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: Re: Added documentation about caching, reliability
Date: Mon, 3 Oct 2005 13:44:59 -0400
Message-ID: <6EE64EF3AB31D5448D0007DD34EEB3417DD4F0@Herge.rcsinc.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [DOCS] Added documentation about caching, reliability
Thread-Index: AcXFCWSzoRe2OLW8Tompyq4n+fgWhgDN6nJg
From: "Merlin Moncure" <merlin.moncure@rcsonline.com>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Peter Eisentraut" <peter_e@gmx.net>, <pgsql-docs@postgresql.org>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.039 required=5 tests=[AWL=-0.011,
	FORGED_RCVD_HELO=0.05]
X-Spam-Level: 
X-Archive-Number: 200510/6
X-Sequence-Number: 3251

Bruce wrote:
> > I was never all that happy with the WAL chapter, since, as you say,
it
> > doesn't seem to be a first-class user-level feature.  I'd be happy
to
> > integrate it into another chapter, but I'm not sure where.
>=20
> Sure, I am looking for suggestions.  My relabeling at least fixes
that,
> but feel free to move things around and relabel them.

FWIW, I agree with Peter.  We are supposed to be talking about Server
Administration, not architectural properties of the database
(reliability, performance, etc.).  The proposed move takes things more
off-topic.  In fact, IMO chapter 26 is already too fat and could provide
links to the 'benefits' and 'implementation details' portions (maybe
move to VII Internals?).

Merlin