Hot standby, conflict resolution

The FATAL and ERROR cancellation modes are quite different. In FATAL
mode, you just want to kill the backend. The target connection doesn't
need to know the LSN.

In ERROR mode, you don't really want to interrupt the target backend. In
ReadBuffer, you're checking a global variable,
BufferRecoveryConflictPending on each call, and if it's set, you check
the buffer's LSN against the LSN of the earliest LSN conflicting LSN,
and throw an error if it's greater than that. Why do we jump through so
many hoops to get the earliest conflicting LSN to where it's needed? At
the moment:

1. Startup process sets the LSN in the target backend's PGPROC entry,
and signals it with SIGINT.
2. The target backend receives the signal; ProcessInterrupts is called
either immediately or at the next CHECK_FOR_INTERRUPTS() call.
3. ProcessInterrupts reads the value from PGPROC, and passes it to bufmgr.c

ISTM that if ReadBuffer read the value directly from the PGPROC entry,
there would be no need for the signaling (in the ERROR mode).

Correct me if I'm wrong, but I thought the idea of this new conflict
resolution was that the startup process doesn't need to wait for the
target backend to die. Instead, the target backend knows to commit
suicide if it stumbles into a buffer that's been modified in a
conflicting way. Looking at ResolveRecoveryConflictWithVirtualXIDs, it
looks like we still wait.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com