On Fri, May 28, 2004 at 01:01:10AM -0400, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > Magnus Hagander wrote: > >> You'd actually need to get a pid *reuse* during that short time. > > > That isn't so implausible on a system which assigns PIDs randomly. > > Holding the SInvalLock doesn't remove the race condition, but it > > makes it less likely to occur for essentially very little cost. > > Other than holding a fairly critical lock for an operation that will > take an unknown amount of time.
With this comment, I take it you'd disagree with my recoding of TransactionIdIsCurrentTransactionId(). The current code has to scan only the xid's in each PGPROC struct. However I had to rewrite it to peek at pg_subtrans, and this is done while the SInvalLock is share-locked. pg_subtrans may need to do some I/O to get the data, and there could be multiple queries, depending on the nesting level. I could write it to save the xid's in PGPROC in a first pass, then release the SInvalLock, then look at pg_subtrans. But I think doing it this way has a ("is a?") race condition. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth) ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match