On Fri, Jan 13, 2012 at 14:46, Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 13, 2012 at 14:42, Greg Smith g...@2ndquadrant.com wrote:
On 01/03/2012 12:59 PM, Tom Lane wrote:
Noah Mischn...@leadboat.com writes:
Regarding the other message, avoid composing a translated message from
On 01/03/2012 12:59 PM, Tom Lane wrote:
Noah Mischn...@leadboat.com 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
On Fri, Jan 13, 2012 at 14:42, Greg Smith g...@2ndquadrant.com wrote:
On 01/03/2012 12:59 PM, Tom Lane wrote:
Noah Mischn...@leadboat.com writes:
Regarding the other message, avoid composing a translated message from
independently-translated parts.
Yes. I haven't looked at the patch,
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
Noah Misch n...@leadboat.com 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
On Mon, Dec 19, 2011 at 15:50, Greg Smith g...@2ndquadrant.com 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
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
On Fri, Dec 16, 2011 at 13:31, Greg Smith g...@2ndquadrant.com 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
On Sat, Dec 17, 2011 at 11:58 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith g...@2ndquadrant.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
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
On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith g...@2ndquadrant.com 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
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
On Friday, December 16, 2011, Robert Haas wrote:
On Fri, Dec 16, 2011 at 1:21 AM, Greg Smith
g...@2ndquadrant.comjavascript:;
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
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.
So
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 have been
On Tue, Dec 13, 2011 at 5:59 AM, Greg Smith g...@2ndquadrant.com 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
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
On Tue, Dec 13, 2011 at 11:59, Greg Smith g...@2ndquadrant.com 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:
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.
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 13, 2011 at 11:59, Greg Smith g...@2ndquadrant.com 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
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
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
Edward Muller edw...@heroku.com 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
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Edward Muller edw...@heroku.com 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,
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Edward Muller edw...@heroku.com 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
26 matches
Mail list logo
