Re: Deriving Recovery Snapshots

Simon Riggs wrote:
> Each backend that existed on the master is represented by a PROC
> structure in the ProcArray. These are known as "recovery procs" and are
> similar to the dummy procs used for prepared transactions. All recovery
> procs are "owned by" the Startup process. So there is no process for
> which MyProc points to one of the recovery procs. This structure allows
> us to record the top-level transactions and then put subtransactions in
> the proc's subtransaction cache. A fixed one-to-one correspondence
> allows efficient maintenance of the structures. We emulate all
> transactional backend, including autovac.

We'll need to know the max_connections setting in the master, in order
to size the array correctly. Not a show-stopper, but would be nicer if
we didn't need to.

> * The backend slot may not be reused for some time, so we should take
> additional actions to keep state current and true. So we choose to log a
> snapshot from the master into WAL after each checkpoint. This can then
> be used to cleanup any unobserved xids. It also provides us with our
> initial state data, see later.

We don't need to log a complete snapshot, do we? Just oldestxmin should
be enough.

> UnobservedXids is maintained as a sorted array. This comes for free
> since xids are always added in xid assignment order. This allows xids to
> be removed via bsearch when WAL records arrive for the missing xids. It
> also allows us to stop searching for xids once we reach
> latestCompletedXid.

If we're going to have an UnobservedXids array, why don't we just treat
all in-progress transactions as Unobserved, and forget about the dummy
PROC entries?

Also, I can't help thinking that this would be a lot simpler if we just
treated all subtransactions the same as top-level transactions. The only
problem with that is that there can be a lot of subtransactions, which
means that we'd need a large UnobservedXids array to handle the worst
case, but maybe it would still be acceptable?

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