README.hotstandby

Faster Archive Recovery and Fast Failover
-----------------------------------------

Startup should be normal for both crash recovery and no-recovery startup.
During archive recovery we begin looking for a consistent point that would
allow queries to be executed safely against the database. This will be
after the point of pg_stop_backup() and also, if recovery has been restarted,
one log file later than the restartpoint. (There is another condition,
discussed later in relation to Hot Standby).

Startup (e.g. pid 8536) will signal postmaster (e.g. pid 8532), who will then
change mode to allow users to connect. At this point the postmaster will 
also spawn the bgwriter (e.g. pid 8541) who then takes responsibility for
writing restartpoints and for cleaning shared buffers, allowing the 
Startup process to continue processing WAL records.

16:27:19 [8536]LOG:  database has now reached consistent state at 0/36000000
16:27:19 [8541]DEBUG:  bgwriter starting during recovery, pid = 8541
16:27:19 [8532]LOG:  database system is ready to accept connections
16:27:19 [8532]LOG:  database can now be accessed with read only transactions
16:29:09 [8536]LOG:  restored log file "000000010000000000000036" from archive
16:29:09 [8541]LOG:  restartpoint starting:
16:29:09 [8541]LOG:  restartpoint complete: wrote 0 buffers (0.0%); write=0.000 s, sync=0.000 s, total=0.001 s
16:29:09 [8541]DEBUG:  recovery restart point at 0/36000020

At the end of recovery, the Startup process exits archive recovery without
writing a shutdown checkpoint. This reduces failover time from minutes to
seconds on large systems. The bgwriter is signalled to perform an immediate
checkpoint so that we can mark the system as operational.

pg_controldata and pg_resetxlog will now show "Minimum safe starting location".

Hot Standby
-----------

"Hot" in this case means that the standby server is active or "hot" and
can connect and execute queries. This is in direct contrast to "warm" standby,
where users could neither connect nor execute queries.

Users who connect recovery will find that their transactions are forced
to be read only. The parameter default_transaction_read_only is set and
cannot be unset during recovery. In addition, a number of administrative
features cannot be used during recovery.

There are no special messages when you connect. If you are unsure whether
the system is in recovery or not you can run
	SELECT pg_is_in_recovery().

Users who connected during recovery will stay connected as the system
comes into normal operational mode.
XXX currently default_transaction_read_only does not auto reset

MVCC for users during Archive Recovery
--------------------------------------

...

Recovery Control functions
--------------------------

see SGML doc files