[WIP PATCH] Lazily assign xids for toplevel Transactions - Mailing list pgsql-hackers

From Florian G. Pflug
Subject [WIP PATCH] Lazily assign xids for toplevel Transactions
Date
Msg-id 46D0A2E4.20405@phlo.org
Whole thread Raw
Responses Re: [WIP PATCH] Lazily assign xids for toplevel Transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I'm resending this without that actual patch attached, since my first
mail didn't get through. The patch can be found here:
http://soc.phlo.org/lazyxidassign.patch

Hi

Lately, there was some interest in assigning XIDs for toplevel Transactions
only when the transaction actually needs one (that is, it writes something
to the disk), like we currently do for subtransactions. This is obviously
also a crucial part of my work on read-only transactions on PITR slaves -
since there is no way to assign "real" XIDs on a PITR slave.

I've spent the last few days factoring out that work, and turning it into
a general solution. The result is this patch, which basically does the following

.) It defines a special TemporaryTransactionId that is used as an xact's xid    until the xact calls
GetCurrentTransactionId/ GetTopTransactionId.
 
.) It introduces a new macro TransactionIdIsPermanent, which tells if an    XID is valid, and not equal to
TemporaryTransactionId.
.) It lets GetTopTransactionId assign an XID on-demand, similar to    how GetCurrentTransactionId handles that for
subtransactions.
.) Each transaction get an "rid" (ResourceOwnerId) assigned when it starts, and    obtains a lock on that rid, similar
tohow the xid is locked. This can    be used to wait for a transaction's toplevel resource owner to release all    it's
locks,and serves as a unique identifier for a running transaction.    This is needed for concurrent index builds to
waituntil all transactions    holding a ShareLock on the target relation have ended.
 

The patch passes the regression test, though there are currently two issues
that need to be resolved.
1) The second waiting phase of concurrent index builds fail to wait for xacts    that haven't been assigned an XID when
thereference shapshot was taken.    The "rid" doesn't help here, because it's not currently store in the    snapshot.
 
2) I'm not entirely sure yet how to handle two flags MyXactMadeTempRelUpdates,    MyXactMadeXLogEntry and the MyRecPtr
variable.Those seems to be made    partly redundant by this patch - checking if an xact has a    permanent xid assigned
alreadytells if the transaction made any writes.
 

(1) could be easiy solves by querying the list of currently active RIDs after
taking the reference snapshot. But since AFAIK HOT introduces a new method for
guaranteeing that a transaction won't use an index that might not contain
all tuples that xact is interested in, I wanted to get feedback on how HOT
currently handles this.

It's probably not the best time to come up with new patches, since everybody
seems to be busy working on getting 8.3 out. But this patch is a quite natural
fallout of my work on read-only queries on PITR slaves, and I'd be very
interested to know if the general direction this patch takes is deemed
acceptable.

greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Best implementation of PATRICIA
Next
From: Alvaro Herrera
Date:
Subject: Re: [ADMIN] reindexdb hangs