From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot standby, recent changes |
Date: | 2009-12-06 20:06:47 |
Message-ID: | 1260130007.13774.46158.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-12-06 22:26:15 | Re: Hot standby, recent changes |
Previous Message | Tom Lane | 2009-12-06 19:43:31 | Re: operator exclusion constraints |