Re: hot standby documentation

On Mon, Jun 21, 2010 at 11:42:03PM -0400, Robert Haas wrote:
> I did some editing of the Hot Standby docs tonight; PFA a proposed patch.
>
> Comments?

In general, +1

> + When the <xref linkend="guc-hot-standby"> parameter is set to true on a
> + standby server, it will begin accepting connections once the recovery has
> + brought the system to a consistent state. All such connections are
> + strictly read-only; not even temporary tables may be written. However,
> + the database system may still use temporary work files internally when
> + executing queries.

I'm not sure it's worth pointing out that the database might still use temp
files. It seems an unnecessary level of detail. I realize you're probably
putting it here because you've edited that bit out of the docs elsewhere, but
I still think it's unnecessary detail. That said, if it has to go somewhere,
+1 for this change.

> - Queries executed on the standby will be correct with regard to the transactions
> - that had been recovered at the start of the query, or start of first statement
> - in the case of serializable transactions. In comparison with the primary,
> - the standby returns query results that could have been obtained on the primary
> - at some moment in the past.
> + Queries executed on the standby will see a view of the database that
> + existed on the master at some moment in the past.

Is it really that non-deterministic? /me admits not having followed that
discussion. Although the original version is pretty complex, it gives the user
some feel for the particular moment in the past that their snapshot will
represent. If the original is incorrect, it would be nice to replace it with
something that doesn't suggest the user might end up with a snapshot from last
week.


> - If cancellation does occur, the query and/or transaction can always
> - be re-executed. The error is dynamic and will not necessarily reoccur
> - if the query is executed again.
> + Cancelled queries may be retried immediately (after beginning a new
> + transaction, of course). Since query cancellation is depending on
> + the nature of the WAL records being replayed, a query that was
> + cancelled may succeed if it is executed again.

s/is depending/depends/

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com