Skip site navigation (1) Skip section navigation (2)

Re: Cancel/Kill backend functions

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>,Magnus Hagander <mha(at)sollentuna(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Cancel/Kill backend functions
Date: 2004-05-28 05:14:55
Message-ID: 20040528051455.GC14710@dcc.uchile.cl (view raw or flat)
Thread:
Lists: pgsql-patches
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)


In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2004-05-28 05:30:01
Subject: Re: Cancel/Kill backend functions
Previous:From: Tom LaneDate: 2004-05-28 05:01:10
Subject: Re: Cancel/Kill backend functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group