From: | Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Hiroyuki Yamada <yamada(at)kokolink(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: alpha3 release schedule? |
Date: | 2009-12-22 11:32:35 |
Message-ID: | 4B30AE53.6020202@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22.12.09 9:34 , Simon Riggs wrote:
> If you are saying being able to start Hot Standby from a shutdown
> checkpoint is an important feature for you, then say so, and why.
I think it's not so much an important feature but more the removal of a
footgun.
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*.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-12-22 11:36:03 | Re: Streaming replication and non-blocking I/O |
Previous Message | Cédric Villemain | 2009-12-22 10:51:55 | Re: Buffer statistics for pg_stat_statements |