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