Robert Haas writes:
> I'm coming around to the point of view that we should just make
> pg_terminate_backend()'s behavior consistent with pg_cancel_backend()
> and call it good.
Yeah, the issues that are really of concern are not ones that that
function in itself can address.
On Wed, Mar 28, 2012 at 10:02 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Andres Freund wrote:
>>> On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
As Tom pointed out, if there's another person sharing the user ID
you're using, and you don't trust them, their ability
"Kevin Grittner" writes:
> Andres Freund wrote:
>> On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
>>> As Tom pointed out, if there's another person sharing the user ID
>>> you're using, and you don't trust them, their ability to cancel
>>> your session is likely way down the list of
On Tue, Mar 27, 2012 at 1:30 PM, Andrew Dunstan wrote:
>> Well, that does sort of leave an arguable vulnerability. Should the
>> same user only be allowed to kill the process from a connection to
>> the same database?
>>
>
> It might be a reasonable restriction in theory, but I doubt it's much of
On 03/27/2012 03:14 PM, Kevin Grittner wrote:
Andres Freund wrote:
On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
Well, I guess if you have different people sharing the same
user-ID, you probably wouldn't want that.
As Tom pointed out, if there's another person sharing the us
Andres Freund wrote:
> On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
>>> Well, I guess if you have different people sharing the same
>>> user-ID, you probably wouldn't want that.
>>
>>
>> As Tom pointed out, if there's another person sharing the user ID
>> you're using, and you d
On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
> > Well, I guess if you have different people sharing the same
> > user-ID, you probably wouldn't want that.
>
>
> As Tom pointed out, if there's another person sharing the user ID
> you're using, and you don't trust them, their abili
On Tue, Mar 27, 2012 at 10:48 AM, Daniel Farina wrote:
> On Tue, Mar 27, 2012 at 10:46 AM, Alvaro Herrera
> wrote:
>> Isn't it the case that many web applications run under some common
>> database user regardless of the underlying webapp user? I wouldn't say
>> that's an unimportant case. Grant
Robert Haas wrote:
> Daniel Farina wrote:
>> Is there a hypothetical DBA that doesn't want a mere-mortal user
>> to be able to signal one of their own backends to do "cancel
>> query, rollback the transaction, then close the socket"? If so,
>> why?
Setting aside possible bugs in the mechanis
On Tue, Mar 27, 2012 at 10:46 AM, Alvaro Herrera
wrote:
> Isn't it the case that many web applications run under some common
> database user regardless of the underlying webapp user? I wouldn't say
> that's an unimportant case. Granted, the webapp user wouldn't have
> permission to run arbitrary
Excerpts from Robert Haas's message of mar mar 27 14:38:47 -0300 2012:
> On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina wrote:
> > On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas wrote:
> >> I think the more important question is a policy question: do we want
> >> it to work like this? It seems li
On Tue, Mar 27, 2012 at 1:46 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar mar 27 14:38:47 -0300 2012:
>> On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina wrote:
>> > On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas wrote:
>> >> I think the more important question is a policy
On Tue, Mar 27, 2012 at 1:26 PM, Daniel Farina wrote:
> On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas wrote:
>> I think the more important question is a policy question: do we want
>> it to work like this? It seems like a policy question that ought to
>> be left to the DBA, but we have no policy
On Mon, Mar 26, 2012 at 4:53 PM, Robert Haas wrote:
> I think the more important question is a policy question: do we want
> it to work like this? It seems like a policy question that ought to
> be left to the DBA, but we have no policy management framework for
> DBAs to configure what they do or
Noah Misch writes:
> On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
>> I think the more important question is a policy question: do we want
>> it to work like this?
> The DBA can customize policy by revoking public execute permissions on
> pg_catalog.pg_terminate_backend and interpo
On Tue, Mar 27, 2012 at 02:58:26PM +0200, Magnus Hagander wrote:
> On Tue, Mar 27, 2012 at 11:04, Noah Misch wrote:
> > On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
> >> I think the more important question is a policy question: do we want
> >> it to work like this? ?It seems like a
On Tue, Mar 27, 2012 at 11:04, Noah Misch wrote:
> On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
>> I think the more important question is a policy question: do we want
>> it to work like this? It seems like a policy question that ought to
>> be left to the DBA, but we have no poli
On Mon, Mar 26, 2012 at 07:53:25PM -0400, Robert Haas wrote:
> I think the more important question is a policy question: do we want
> it to work like this? It seems like a policy question that ought to
> be left to the DBA, but we have no policy management framework for
> DBAs to configure what th
Robert Haas writes:
> I think the more important question is a policy question: do we want
> it to work like this? It seems like a policy question that ought to
> be left to the DBA, but we have no policy management framework for
> DBAs to configure what they do or do not wish to allow. Still, i
Daniel Farina writes:
> On Mon, Mar 26, 2012 at 1:57 PM, Tom Lane wrote:
>> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
>> production database.
> Okay, it was my precise intention to hand this to users so that not
> only could they cancel their queries, but also force
On Mon, Mar 26, 2012 at 4:57 PM, Tom Lane wrote:
>> I'm not sure - perhaps we're past that worry these days?
>
> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
> production database. It'll probably work, but what if it doesn't?
> Best-case scenario is you'll need to do a p
On Mon, Mar 26, 2012 at 1:57 PM, Tom Lane wrote:
> I'm not. I still wouldn't trust SIGTERMing an individual backend in a
> production database. It'll probably work, but what if it doesn't?
> Best-case scenario is you'll need to do a panic shutdown to clear the
> stuck lock or whatever that the b
Magnus Hagander writes:
> I wasn't aware that was the reason there. I think it was the general
> "leftovers" from previous times. When we first created
> pg_terminate_backend() there was a general thought that it might not
> be safe to just SIGTERM a backend to make it quit.
Not just "might not b
On Tue, Mar 20, 2012 at 18:48, Daniel Farina wrote:
> On Tue, Mar 20, 2012 at 10:13 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Maybe we should just not worry about this.
>>
>> That's been my reaction right along. There's no evidence that PID
>> recycling is a problem in the real world.
>
>
On Tue, Mar 20, 2012 at 10:13 AM, Tom Lane wrote:
> Robert Haas writes:
>> Maybe we should just not worry about this.
>
> That's been my reaction right along. There's no evidence that PID
> recycling is a problem in the real world.
I'm entirely willing to acquiesce to that point of view. I onl
Robert Haas writes:
> Maybe we should just not worry about this.
That's been my reaction right along. There's no evidence that PID
recycling is a problem in the real world.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, Mar 20, 2012 at 12:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I'm not sure it would save anything meaningful to read the PID
>> after releasing the lock even if it were safe, so I'd be inclined to
>> keep things simple. But on further reflection I had us using the PID
>> to fi
Robert Haas writes:
> Well, I'm not sure it would save anything meaningful to read the PID
> after releasing the lock even if it were safe, so I'd be inclined to
> keep things simple. But on further reflection I had us using the PID
> to find the target PGPROC in the first place, so we don't need
On Tue, Mar 20, 2012 at 4:35 AM, Daniel Farina wrote:
> I chose the SessionId mostly because I didn't have a great sense
> around how hot the ProcArrayLock is, and it was easy to add a
> fine-grained spinlock to just get the flavor of the idea.
It's fairly hot, but terminating or canceling backen
On Mon, Mar 19, 2012 at 9:08 PM, Robert Haas wrote:
> It's after midnight here so maybe I'm being slow, but I don't
> understand what problem the SessionId solves. ISTM that you could
> solve the problem like this:
>
> 1. Acquire ProcArrayLock in exclusive mode, to keep the set of PGPROCs
> from
On Sat, Mar 17, 2012 at 8:28 PM, Daniel Farina wrote:
> This thread evolved out of an attempt to implement
> pg_terminate_backend for non-superusers. I thought -- probably
> erroneously -- that the major objection to that was the known
> possibility of a PID-cycling race condition, whereby a sign
On Sun, Mar 18, 2012 at 01:28, Daniel Farina wrote:
> Noah offered me these comments:
>> This patch still changes the policy for pg_terminate_backend(), and it does
>> not fix other SIGINT senders like processCancelRequest() and ProcSleep(). If
>> you're concerned about PID-reuse races, audit all
32 matches
Mail list logo
