Re: [HACKERS] recovery consistent != hot standby
On Fri, May 14, 2010 at 5:23 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] recovery consistent != hot standby
Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
