Re: Hot standby, recovery procs

Forgot attachment, here it is as a patch against CVS HEAD. It's also in
my git repository.

Heikki Linnakangas wrote:
> 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