Re: Hot standby, recent changes - Mailing list pgsql-hackers
From | Simon Riggs |
---|---|
Subject | Re: Hot standby, recent changes |
Date | |
Msg-id | 1260130007.13774.46158.camel@ebony Whole thread Raw |
In response to | Re: Hot standby, recent changes (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Responses |
Re: Hot standby, recent changes
|
List | pgsql-hackers |
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. -- Simon Riggs www.2ndQuadrant.com
pgsql-hackers by date: