Re: alpha3 release schedule?

On 22.12.09 13:21 , Simon Riggs wrote:
> On Tue, 2009-12-22 at 12:32 +0100, Florian Pflug wrote:
>> Image a reporting database where all transactions but a few daily
>> bulk imports are read-only. To spread the load, you do your bulk
>> loads on the master, but run the reporting queries against a
>> read-only HS slave. Now you take the master down for maintenance.
>> Since all clients but the bulk loader use the slave already, and
>> since the bulk loads can be deferred until after the maintenance
>> window closes again, you don't actually do a fail-over.
>>
>> Now you're already pointing at your foot with the gun. All it
>> takes to ruin your day is *some* reason for the slave to restart.
>> Maybe due to a junior DBA's typo, or maybe due to a bug in
>> postgres. Anway, once the slave is down, it won't come up until you
>> manage to get the master up and running again. And this limitation
>> is pretty surprising, since one would assume that if the slave
>> survives a *crash* of the master, it'd certainly survive a simple
>> *shutdown*.
>
> Well, you either wait for master to come up again and restart, or you
> flip into normal mode and keep running queries from there. You aren't
> prevented from using the server, except by your own refusal to
> failover.

Very true. However, that "refusal" as you put it might actually be the
most sensible thing to do in a lot of setups. Not everyone needs extreme
up-time guarantees, and for those people setting up, testing and
*continuously* exercising fail-over is just not worth the effort.
Especially since fail-over with asynchronous replication is tricky to
get right if you want to avoid data loss.

So I still believe that there are very real use-cases for HS where this
limitation can be quite a PITA.

But you are of course free to work on whatever you feel like, and
probably need to satisfy your client's needs first. So I'm in no way
implying that this issue is a must-fix issue, or that you're in any way
obliged to take care of it. I merely wanted to make the point that there
*are* valid use-cases where this behavior is not ideal.

best regards,
Florian Pflug