Re: Cancel/Kill backend functions

On Fri, May 28, 2004 at 01:01:10AM -0400, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> 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)