Re: Hot standby, recent changes - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Hot standby, recent changes |
Date | |
Msg-id | 603c8f070912061426h5301b6e5jfa5cd03ea39cb88e@mail.gmail.com Whole thread Raw |
In response to | Re: Hot standby, recent changes (Simon Riggs <simon@2ndQuadrant.com>) |
Responses |
Re: Hot standby, recent changes
Re: Hot standby, recent changes |
List | pgsql-hackers |
On Sun, Dec 6, 2009 at 3:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote: >> Simon Riggs wrote: >> > On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote: >> >> 4. Need to handle the case where master is started up with >> >> wal_standby_info=true, shut down, and restarted with >> >> wal_standby_info=false, while the standby server runs continuously. And >> >> the code in StartupXLog() to initialize recovery snapshot from a >> >> shutdown checkpoint needs to check that too. >> > >> > I don't really understand the use case for shutting down the server and >> > then using it as a HS base backup. Why would anyone do that? Why would >> > they have their server down for potentially hours, when they can take >> > the backup while the server is up? If the server is idle, it can be >> > up-and-idle just as easily as down-and-idle, in which case we wouldn't >> > need to support this at all. Adding yards of code for this capability >> > isn't important to me. I'd rather strip the whole lot out than keep >> > fiddling with a low priority area. Please justify this as a real world >> > solution before we continue trying to support it. >> >> This affects using a shutdown checkpoint as a recovery start point >> (restore point) in general, not just a fresh backup taken from a shut >> down database. >> >> Consider this scenario: >> >> 0. You have a master and a standby configured properly, and up and running. >> 1. You shut down master for some reason. >> 2. You restart standby. For some reason. Maybe by accident, or you want >> to upgrade minor version or whatever. >> 3. Standby won't accept connections until the master is started too. >> Admin says "WTF?" > > OK, I accept that as a possible scenario. > > I'm concerned that the number of possible scenarios we are trying to > support in the first version is too high, increasing the likelihood that > some of them do not work correctly because the test scenarios didn't > re-create them exactly. > > In the above scenario, if it is of serious concern the admin can > failover to the standby and then access the standby for queries. If the > master was down for any length of time that's exactly what we'd expect > to happen anyway. > > So I don't see the scenario as very likely; I'm sure it will happen to > somebody. In any case, it is in the opposite direction to the main > feature, which is a High Availability server, so any admin that argued > that he wanted to have his HA standby stay as a standby in this case > would likely be in a minority. > > I would rather document it as a known caveat and be done. For what it's worth, this doesn't seem particularly unlikely or unusual to me. But on the other hand, I do really want to get this committed soon, and I don't have time to help at the moment, so maybe I should keep my mouth shut. ...Robert
pgsql-hackers by date: