Re: pg_terminate_backend for same-role

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_terminate_backend for same-role
Date: 2012-03-16 05:41:05
Message-ID: CAAZKuFbt2PTNt=8YLn39A9YoMPVMOMS6hgmJReXowH=e9pxj+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)com> writes:
>> The way MyCancelKey is checked now is backwards, in my mind.  It seems
>> like it would be better checked by the receiving PID (one can use a
>> check/recheck also, if so inclined).  Is there a large caveat to that?
>
> You mean, other than the fact that kill(2) can't transmit such a key?

I was planning on using an out-of-line mechanism. Bad idea?

> But actually I don't see what you hope to gain from such a change,
> even if it can be made to work.  Anyone who can do kill(SIGINT) can
> do kill(SIGKILL), say --- so you have to be able to trust the signal
> sender.  What's the point of not trusting it to verify the client
> identity?

No longer true with pg_cancel_backend not-by-superuser, no? Now there
are new people who can do kill(SIGINT) (modulus the already existing
cancel requests).

--
fdr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-16 05:45:45 Re: pg_terminate_backend for same-role
Previous Message Tom Lane 2012-03-16 05:33:45 Re: pg_terminate_backend for same-role