Subject: hot standby documentation

From: Robert Haas <[email-masked]>
Date: Mon, 21 Jun 2010 23:42:03 -0400

I did some editing of the Hot Standby docs tonight; PFA a proposed patch.

Comments?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

---

From: Joshua Tolley <[email-masked]>
Date: Tue, 22 Jun 2010 06:56:11 -0600

> I did some editing of the Hot Standby docs tonight; PFA a proposed patch.

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

---

From: Robert Haas <[email-masked]>
Date: Tue, 22 Jun 2010 14:24:55 -0400

> I still think it's unnecessary detail. That said, if it has to go somewhere,

I agree, and your guess about how it ended up there is correct.  Removed.

> something that doesn't suggest the user might end up with a snapshot from last

I had another go at this.

> s/is depending/depends/

Fixed.  See attached.

---

From: Joshua Tolley <[email-masked]>
Date: Tue, 22 Jun 2010 17:04:03 -0600

> I had another go at this.

Much better, IMO.

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

---

From: Simon Riggs <[email-masked]>
Date: Wed, 23 Jun 2010 19:53:54 +0100

> Fixed.  See attached.

I started reading this but by chunk seven I only agree with a couple of
these changes. None of them seem hugely important changes.

I'd suggest you make a pass of copy editing that doesn't seek to alter
the meanings or add information, so we can agree without discussing each
proposed change in detail. Definitely don't remove information.

It's not impossible to believe that temp tables could be written in the
future, so I disagree with the comments there.

We could also allow SELECT ... FOR SHARE during Hot Standby, simply by
making it same as normal SELECT, without any ill effects.

-- 
 Simon Riggs           www.2ndQuadrant.com

---

From: Robert Haas <[email-masked]>
Date: Wed, 23 Jun 2010 15:05:33 -0400

> proposed change in detail. Definitely don't remove information.

I've actually removed very little.  The current text repeats some
information or splits up related facts across different paragraphs.

> future, so I disagree with the comments there.

The text I wrote does not say that temp tables could not be written in
the future.  It simply says why they cannot be written now.

> making it same as normal SELECT, without any ill effects.

True.

---

From: Robert Haas <[email-masked]>
Date: Wed, 23 Jun 2010 15:14:41 -0400

>> making it same as normal SELECT, without any ill effects.

Actually, wait a minute.  Why wouldn't we need to lock the tuples on
the standby just as we do on the primary?  Sure, there can't be
another user transaction modifying those tuples, but WAL replay could
still modify them.

Anyhow, I think that's beside the point.  The documentation just says
what Hot Standby does, not what it might do in a future release.  And
I don't think this patch changes that very much at all.

---

From: Heikki Linnakangas <[email-masked]>
Date: Wed, 23 Jun 2010 22:29:54 +0300

On 23/06/10 22:05, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs<[email-masked]>  wrote:

Not really. It won't matter while the standby is in read-only mode, but 
as soon as the server is promoted to master, you could have other 
backends modifying rows that the still-running "SELECT ... FOR SHARED" 
transaction should have locked.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com