Thread: hot standby documentation
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
Attachment
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
Attachment
On Tue, Jun 22, 2010 at 8:56 AM, Joshua Tolley <eggyknap@gmail.com> wrote: > 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. I agree, and your guess about how it ended up there is correct. Removed. >> - 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. I had another go at this. > s/is depending/depends/ Fixed. See attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Attachment
On Tue, Jun 22, 2010 at 02:24:55PM -0400, Robert Haas wrote: > On Tue, Jun 22, 2010 at 8:56 AM, Joshua Tolley <eggyknap@gmail.com> wrote: > >> - 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. > > I had another go at this. Much better, IMO. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
Attachment
On Tue, 2010-06-22 at 14:24 -0400, Robert Haas wrote: > 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
On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Tue, 2010-06-22 at 14:24 -0400, Robert Haas wrote: > >> 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. I've actually removed very little. The current text repeats some information or splits up related facts across different paragraphs. > It's not impossible to believe that temp tables could be written in the > 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. > We could also allow SELECT ... FOR SHARE during Hot Standby, simply by > making it same as normal SELECT, without any ill effects. True. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Wed, Jun 23, 2010 at 3:05 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> We could also allow SELECT ... FOR SHARE during Hot Standby, simply by >> making it same as normal SELECT, without any ill effects. > > True. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On 23/06/10 22:05, Robert Haas wrote: > On Wed, Jun 23, 2010 at 2:53 PM, Simon Riggs<simon@2ndquadrant.com> wrote: >> We could also allow SELECT ... FOR SHARE during Hot Standby, simply by >> making it same as normal SELECT, without any ill effects. > > True. 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