On Wed, 2008-10-22 at 20:42 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Wed, 2008-10-22 at 17:18 +0300, Heikki Linnakangas wrote:
> >
> >> It doesn't need to be in subtrans before it appears on
> >> disk, AFAICS.
> >
> > I don't make these rules. Read comments in AssignTransactionId().
>
> You mean this one:
>
> > /*
> > * Generate a new Xid and record it in PG_PROC and pg_subtrans.
> > *
> > * NB: we must make the subtrans entry BEFORE the Xid appears anywhere in
> > * shared storage other than PG_PROC; because if there's no room for it in
> > * PG_PROC, the subtrans entry is needed to ensure that other backends see
> > * the Xid as "running". See GetNewTransactionId.
> > */
>
> ? The way I read that is that as long as there's an entry in
> UnobservedXids, we don't need a subtrans entry.
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.
That suggests a nice optimisation we can use in normal running and with
the Hot Standby patch, but it doesn't provide an alternate approach.
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.
(The optimisation is for AssignTransactionId() to not update subtrans
for the first PGPROC_MAX_CACHED_SUBXIDS subtransactions, either in
AssignTransactionId() or in xact_redo_commit(). That would mean in most
normal cases we would never update subtrans at all. It requires a slight
change to the way XidInMVCCSnapshot() works, but I've already included
that change in the current patch. I'll do that as a standalone patch.)
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
