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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
