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

Re: Cancel/Kill backend functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>,Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,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:01:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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.

Since PG is not root, even if the PID has been reused, it's not possible
to kill some random process with this.  You could only kill another
postgres process, and in practice this would more or less have to be a
new backend that had gotten reassigned the same PID just abandoned a
moment before by the one you intended to kill.

I don't think this is a very likely scenario.  In fact, I suspect there
are interlocks in the kernel to prevent recycling a PID quite that
quickly, because otherwise practically *any* use of kill() would be too
hazardous to contemplate.

>> Bottom line -  while maybe slightly more correcet, not sure it's
>> necessary.

> IMHO it's worth doing.

I disagree.

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-05-28 05:14:55
Subject: Re: Cancel/Kill backend functions
Previous:From: Claudio NatoliDate: 2004-05-28 03:09:23
Subject: Re: win32 locale fixes

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