Thread: recovery consistent != hot standby
While looking through postmaster.c and xlog.c I discovered that we're being a little bit loose about our use of terminology. Maybe this was right when committed (I think, at that point, Hot Standby was always on) but it's not right any more. It appears that we only enter the PM_RECOVERY_CONSISTENT when Hot Standby is enabled; otherwise, we remain in PM_RECOVERY even after reaching consistency. I think, then, that the state, and the signal which triggers it are misnamed. For the avoidance of confusion, I'd like to propose that we rename as follows: PM_RECOVERY_CONSISTENT -> PM_HOT_STANDBY PMSIGNAL_RECOVERY_CONSISTENT -> PMSIGNAL_BEGIN_HOT_STANDBY Objections? Better ideas? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes:
> PM_RECOVERY_CONSISTENT -> PM_HOT_STANDBY
> PMSIGNAL_RECOVERY_CONSISTENT -> PMSIGNAL_BEGIN_HOT_STANDBY
+1. From the point of view of the postmaster, whether the state
transition happens immediately upon reaching consistency, or at a
later time, or perhaps even earlier (if we could make that work)
is not relevant. What's relevant is that it's allowed to let in
hot-standby backends. So the current naming overspecifies the
meaning of the state and the transition event.
regards, tom lane
On Fri, May 14, 2010 at 5:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> PM_RECOVERY_CONSISTENT -> PM_HOT_STANDBY >> PMSIGNAL_RECOVERY_CONSISTENT -> PMSIGNAL_BEGIN_HOT_STANDBY > > +1. From the point of view of the postmaster, whether the state > transition happens immediately upon reaching consistency, or at a > later time, or perhaps even earlier (if we could make that work) > is not relevant. What's relevant is that it's allowed to let in > hot-standby backends. So the current naming overspecifies the > meaning of the state and the transition event. Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company