Hot Standby and handling max_standby_delay
in [PgSql]
|
From: Tom Lane on 18 Jan 2010 10:24 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Tom Lane wrote: >> Whether or not anyone bothers with the timestamp message, I think adding >> a message type header is a Must Fix item. A protocol with no provision >> for extension is certainly going to bite us in the rear before long. > Agreed a message type header is a good idea, although we don't expect > streaming replication and the protocol to work across different major > versions anyway. Speaking of which, just where is the defense that makes sure that walsender and walreceiver are compatible? We should be checking not only version, but all of the configuration variables that are embedded in pg_control. 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: Heikki Linnakangas on 18 Jan 2010 12:30 Tom Lane wrote: > Speaking of which, just where is the defense that makes sure that > walsender and walreceiver are compatible? We should be checking not > only version, but all of the configuration variables that are embedded > in pg_control. That happens at startup when pg_control is read, before streaming starts. Remember that you need to start with a base backup. We also check that the system_identifier in the standby matches that in the primary, when the connection is established. That protects you from starting streaming from wrong base backup. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: [HACKERS] Hot Standby and handling max_standby_delay Next: Mammoth in Core? |