Dimitri Fontaine wrote: > But how we handle failures when transitioning from one state to the > other should be a lot easier to discuss and decide as soon as we have > the possible states and the transitions we want to allow and support. I > think. > > My guess is that those states and transitions are in the code, but not > explicit, so that each time we talk about how to handle the error cases > we have to be extra verbose and we risk not talking about exactly the > same thing. Naming the states should make those arrangements easier, I > should think. Not sure if it would help follow the time constraint now > though.
I agree, a state machine is a useful way of thinking about this. I recall that mail of yours from last summer :-). The states we have at the moment in standby are: 1. Archive recovery. Standby fetches WAL files from archive using restore_command. When a file is not found in archive, we switch to state 2 2. Streaming replication. Standby connects (and reconnects if the connection is lost for any reason) to the primary, starts streaming, and applies WAL as it arrives. We stay in this state until trigger file is found or server is shut down. The states with my suggested ReadRecord/FetchRecord refactoring, the code I have in the replication-xlogrefactor branch in my git repo, are: 1. Initial archive recovery. Standby fetches WAL files from archive using restore_command. When a file is not found in archive, we start walreceiver and switch to state 2 2. Retrying to restore from archive. When the connection to primary is established and replication is started, we switch to state 3 3. Streaming replication. Connection to primary is established, and WAL is applied as it arrives. When the connection is dropped, we go back to state 2 Although the the state transitions between 2 and 3 are a bit fuzzy in that version; walreceiver runs concurrently, trying to reconnect, while startup process retries restoring from archive. Fujii-san's suggestion to have walreceiver stop while startup process retries restoring from archive (or have walreceiver run restore_command in approach #2) would make that clearer. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
