From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch to allow users to kill their own queries |
Date: | 2011-12-18 04:58:26 |
Message-ID: | 21859.1324184306@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> ... If you assume someone can run through all the
>> PIDs between those checks and the kill, the system is already broken that
>> way.
> From a theoretical point of view, I believe it to be slightly
> different. If a superuser sends a kill, they will certainly be
> authorized to kill whatever they end up killing, because they are
> authorized to kill anything. On the other hand, the proposed patch
> would potentially result - in the extremely unlikely event of a
> super-fast PID wraparound - in someone cancelling a query they
> otherwise wouldn't have been able to cancel.
> In practice, the chances of this seem fairly remote.
I think this argument is bogus: if this is a real issue, then no use of
kill() anytime, by anyone, is safe. In practice I believe that Unix
systems avoid recycling PIDs right away so as to offer some protection.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-12-18 05:04:19 | Re: Command Triggers |
Previous Message | Tom Lane | 2011-12-18 04:09:39 | Re: Allow substitute allocators for PGresult. |