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