Hi, > >> So our proposal on this problem is that we must ensure that master should > not make any file system level changes without confirming that the >> corresponding WAL record is replicated to the standby. > > How will you take care of extra WAL on old master during recovery. If it > plays the WAL which has not reached new-master, it can be a problem. >
I am trying to understand how there would be extra WAL on old master that it would replay and cause inconsistency. Consider how I am picturing it and correct me if I am wrong. 1) Master crashes. So a failback standby becomes new master forking the WAL. 2) Old master is restarted as a standby (now with this patch, without a new base backup). 3) It would try to replay all the WAL it has available and later connect to the new master also following the timeline switch (the switch might happen using archived WAL and timeline history file OR the new switch-over-streaming-replication-connection as of 9.3, right?) * in (3), when the new standby/old master is replaying WAL, from where is it picking the WAL? Does it first replay all the WAL in pg_xlog before archive? Should we make it check for a timeline history file in archive before it starts replaying any WAL? * And, would the new master, before forking the WAL, replay all the WAL that is necessary to come to state (of data directory) that the old master was just before it crashed? Am I missing something here? -- Amit Langote -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
