On Fri, Jan 13, 2012 at 14:46, Magnus Hagander wrote:
> On Fri, Jan 13, 2012 at 14:42, Greg Smith wrote:
>> On 01/03/2012 12:59 PM, Tom Lane wrote:
>>>
>>> Noah Misch writes:
>>>
Regarding the other message, avoid composing a translated message from
independently-translated parts.
On Fri, Jan 13, 2012 at 14:42, Greg Smith wrote:
> On 01/03/2012 12:59 PM, Tom Lane wrote:
>>
>> Noah Misch writes:
>>
>>>
>>> Regarding the other message, avoid composing a translated message from
>>> independently-translated parts.
>>>
>>
>> Yes. I haven't looked at the patch, but I wonder whe
On 01/03/2012 12:59 PM, Tom Lane wrote:
Noah Misch writes:
Regarding the other message, avoid composing a translated message from
independently-translated parts.
Yes. I haven't looked at the patch, but I wonder whether it wouldn't be
better to dodge both of these problems by having
Noah Misch writes:
> Regarding the other message, avoid composing a translated message from
> independently-translated parts.
Yes. I haven't looked at the patch, but I wonder whether it wouldn't be
better to dodge both of these problems by having the subroutine return a
success/failure result co
On Tue, Dec 20, 2011 at 02:30:08PM +0100, Magnus Hagander wrote:
> That said - can someone who knows the translation stuff better than me
> comment on if this is actually going to be translatable, or if it
> violates too many translation rules?
> +pg_signal_backend(int pid, int sig, bool allow_sam
On Mon, Dec 19, 2011 at 15:50, Greg Smith wrote:
> On 12/18/2011 07:31 AM, Magnus Hagander wrote:
>>
>> * I restructured the if statements, because I had a hard time
>> following the comments around that ;) I find this one easier - but I'm
>> happy to change back if you think your version was more
On 12/18/2011 07:31 AM, Magnus Hagander wrote:
* I restructured the if statements, because I had a hard time
following the comments around that ;) I find this one easier - but I'm
happy to change back if you think your version was more readable.
That looks fine. I highlighted this because I ha
On Sat, Dec 17, 2011 at 11:58 PM, Tom Lane wrote:
> 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.
I'm not sure they do anythin
On Fri, Dec 16, 2011 at 13:31, Greg Smith wrote:
> On 12/14/2011 05:24 AM, Magnus Hagander wrote:
>>
>> How about passing a parameter to pg_signal_backend? Making
>> pg_signal_backend(int pid, int sig, bool allow_samerole)?
>>
>
>
> That works, got rid of the parts I didn't like and allowed some u
Robert Haas writes:
> On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith 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 su
Excerpts from Greg Smith's message of vie dic 16 11:19:52 -0300 2011:
> On 12/16/2011 08:42 AM, Robert Haas wrote:
> > 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 h
On Friday, December 16, 2011, Greg Smith wrote:
> On 12/16/2011 08:42 AM, Robert Haas wrote:
>
>> 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.
On Friday, December 16, 2011, Robert Haas wrote:
> On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith
> >
> wrote:
> > This is a problem with the existing code though, and the proposed changes
> > don't materially alter that; there's just another quick check in one path
> > through. Right now we check
On 12/16/2011 08:42 AM, Robert Haas wrote:
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.
So how might this get exploited?
-Attach a debugger and
On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith wrote:
> This is a problem with the existing code though, and the proposed changes
> don't materially alter that; there's just another quick check in one path
> through. Right now we check if someone is superuser, then if it's a backend
> PID, then we s
On 12/14/2011 05:24 AM, Magnus Hagander wrote:
How about passing a parameter to pg_signal_backend? Making
pg_signal_backend(int pid, int sig, bool allow_samerole)?
That works, got rid of the parts I didn't like and allowed some useful
minor restructuring. I also made the HINT better and m
On 12/15/2011 07:36 PM, Josh Kupershmidt wrote:
The only niggling concern I have about this patch (and, I think, all
similar ones proposed) is the possible race condition between the
permissions checking and the actual call of kill() inside
pg_signal_backend().
This is a problem with the existi
On Tue, Dec 13, 2011 at 5:59 AM, Greg Smith wrote:
> Same-user cancels, but not termination. Only this, and nothing more.
+1 from me on this approach. I think enough people have clamored for
this simple approach which solves the common-case.
> There's one obvious and questionable design decisio
Magnus Hagander writes:
> On Tue, Dec 13, 2011 at 11:59, Greg Smith wrote:
>> HINT: you can use pg_cancel_backend() on your own processes
> That HINT sounds a bit weird to me. "you can cancel your own queries
> using pg_cancel_backend() instead" or something like that?
Doesn't follow message s
On 12/14/2011 05:24 AM, Magnus Hagander wrote:
How about passing a parameter to pg_signal_backend? Making
pg_signal_backend(int pid, int sig, bool allow_samerole)?
That sounds like it will result in less code, and make the API I was
documenting be obvious from the parameters instead. I'll
On Tue, Dec 13, 2011 at 11:59, Greg Smith wrote:
> The submission from Edward Muller I'm replying to is quite similar to what
> the other raging discussion here decided was the right level to target.
> There was one last year from Josh Kupershmidt with similar goals:
> http://archives.postgresql
The submission from Edward Muller I'm replying to is quite similar to
what the other raging discussion here decided was the right level to
target. There was one last year from Josh Kupershmidt with similar
goals: http://archives.postgresql.org/pgsql-admin/2010-02/msg00052.php
A good place to
On 11/16/2011 01:28 PM, Daniel Farina wrote:
As it would turn out, a patch for this has already been submitted:
http://archives.postgresql.org/pgsql-hackers/2011-10/msg1.php
There was some wrangling on whether it needs to be extended to be
useful, but for our purposes the formulation already
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wrote:
>
>> Looking for comments ...
>>
>> https://gist.github.com/be937d3a7a5323c73b6e
>>
>> We'd like to get this, or something like it, into 9.2
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wr
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wrote:
>
>> Looking for comments ...
>>
>> https://gist.github.com/be937d3a7a5323c73b6e
>>
>> We'd like to get this, or something like it, into 9.2
>
> If you want it to be seriously considered, you should post the patch
> to
Edward Muller wrote:
> Looking for comments ...
>
> https://gist.github.com/be937d3a7a5323c73b6e
>
> We'd like to get this, or something like it, into 9.2
If you want it to be seriously considered, you should post the patch
to this list, which makes it part of the permanent archives and
indi
Looking for comments ...
https://gist.github.com/be937d3a7a5323c73b6e
We'd like to get this, or something like it, into 9.2
PS Subscribing to psql-hack...@postgresql.org just spins for me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
27 matches
Mail list logo