Simon Riggs wrote:
> If you don't mark subtrans, you will need to keep things in shared
> memory. I agree you can defer marking subtrans until your shared memory
> fills, but you will still need to keep track of the parent for each
> subtransaction until you do. If you don't *know* the parent, how will
> you do this? You haven't explained how you will write the relationship
> between a subtransaction and its parent into WAL, for each
> subtransaction and for an arbitrarily large number of subtransactions.
I was thinking that it's done in AssignTransactionId(). Similarly to
what you're doing in your patch, but instead of just one xid with it's
parent, a list of (xid, parent) pairs would be stored in the WAL record.
Upon replaying that WAL record, those parent-child relationships are
recorded in subtrans, and the child xids are removed from UnobservedXids.
> We seem to be scrabbling around looking for a second solution. Even if
> we find one you'll need to show that its substantially better than the
> one that's already on the table. But right now it doesn't seem like
> we're on the verge of a radically better approach, for this part.
I'm trying to tease apart the important aspects of the design, and
trying to reduce it into the simplest thing that can work. For example,
since it seems like we need UnobservedXids array anyway, can we use just
that, and not need the PROC entries? And if we need to sometimes WAL log
in AssignTransactionId(), could we use just that one mechanism for
transferring parent-child relationships, and not need the extra field in
all WAL records? The less mechanisms there is to do stuff, the simpler
the patch, the less codepaths to test, and so forth.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com