recovery consistent != hot standby
in [PgSql]
|
Prev: Parameter oddness; was HS/SR Assert server crash
Next: Generating Lots of PKs with nextval(): A Feature Proposal
From: Tom Lane on 14 May 2010 17:23 Robert Haas <robertmhaas(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 15 May 2010 16:01
On Fri, May 14, 2010 at 5:23 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |