Re: pg_terminate_backend for same-role
От | Daniel Farina |
---|---|
Тема | Re: pg_terminate_backend for same-role |
Дата | |
Msg-id | CAAZKuFbt2PTNt=8YLn39A9YoMPVMOMS6hgmJReXowH=e9pxj+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_terminate_backend for same-role (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_terminate_backend for same-role
|
Список | pgsql-hackers |
On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Daniel Farina <daniel@heroku.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
В списке pgsql-hackers по дате отправления: