Re: Hot standby, recovery procs

Simon Riggs wrote:
> On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
>>> What benefit would we gain from separating them, especially since we now
>>> have working, tested code?
>> Simplicity. That matters a lot. Removing the distinction between 
>> unobserved xids and already-observed running transactions would slash a 
>> lot of code.
> 
> It might and it might not, but I don't believe all angles have been
> evaluated. But I would say that major changes such as this have resulted
> in weeks of work. More bugs have been introduced since feature freeze
> than were present beforehand. 

Here's a rough sketch of how the transaction tracking could work without 
recovery procs, relying on unobserved xids array only. The "unobserved 
xids" is a complete misnomer now, as it tracks all master-transactions, 
and there's no distinction between observed and unobserved ones.

Another big change in this patch is the way xl_xact_assignment records 
work. Instead of issuing one such WAL record for each subtransaction 
when they're being assigned recursively, we keep track of which xids 
have already been "reported" in the WAL (similar to what you had in an 
earlier version of the patch). Whenever you hit the limit of 64 
unreported subxids, you issue a single WAL record listing all the 
unreported subxids of this top-level transactions, and mark them as 
reported. The limit of 64 is chosen arbitrarily, but it should match the 
number of slots in the unobserved xids array per backend, to avoid 
running out of slots. This eliminates the need for the xl_topxid field 
in the WAL record header. I think one WAL record per 64 assigned 
subtransactions is a small price to pay, considering that a transaction 
with that many subtransactions is probably doing some interesting work 
anyway, and the volume of those assignment WAL records is lost in the 
noise of all the other WAL records the transactions issues.

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