On Wed, Jun 27, 2012 at 8:13 AM, Magnus Hagander wrote:
>> I went ahead and committed this.
>>
>> I kinda think we should back-patch this into 9.2. It doesn't involve
>> a catalog change, and would make the behavior consistent between the
>> two releases, instead of changing in 9.1 and then chang
On Tue, Jun 26, 2012 at 10:58 PM, Robert Haas wrote:
> On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
>> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri,
On Tue, Jun 26, 2012 at 1:58 PM, Robert Haas wrote:
> On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
>> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri,
On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote:
> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
>>> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>>> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>>> >> Paral
On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote:
> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
>> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>> >> Parallel to pg_cancel_backend, it'd be nice to allow the user to j
On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote:
> On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> > On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
> >> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> >> outright kill a backend that they own (politely,
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
> On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
>> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
>> outright kill a backend that they own (politely, with a SIGTERM),
>> aborting any transactions in progress, inclu
On Fri, Mar 16, 2012 at 04:42:07PM -0700, Daniel Farina wrote:
> On Fri, Mar 16, 2012 at 3:42 PM, Noah Misch wrote:
> > On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
> >> I imagine the problem is a race condition whereby a pid might be
> >> reused by another process owned by anoth
On Fri, Mar 16, 2012 at 4:42 PM, Daniel Farina wrote:
> Hmm. Well, here's a patch that implements exactly that, I think,
That version had some screws loose due to some editor snafus.
Hopefully all better.
--
fdr
Implement-race-free-sql-originated-backend-cancellation-v3.patch.gz
Description:
On Fri, Mar 16, 2012 at 3:42 PM, Noah Misch wrote:
> On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
>> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
>> outright kill a backend that they own (politely, with a SIGTERM),
>> aborting any transactions in progress
On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> outright kill a backend that they own (politely, with a SIGTERM),
> aborting any transactions in progress, including the idle transaction,
> and closing the socke
On Thu, Mar 15, 2012 at 11:01 PM, Daniel Farina wrote:
> Okay, well, I believe there is a race in handling common
> administrative signals that *might* possibly matter. In the past,
> pg_cancel_backend was superuser only, which is a lot like saying "only
> available to people who can be the postg
On Thu, Mar 15, 2012 at 10:45 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane wrote:
>>> 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
Daniel Farina writes:
> On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane wrote:
>> 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.
On Thu, Mar 15, 2012 at 10:33 PM, Tom Lane wrote:
> Daniel Farina 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?
>
>
Daniel Farina 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 s
On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote:
>> Shall we just do everything using the
>> MyCancelKey (which I think could just be called "SessionKey",
>> "SessionSecret", or even just "Session") as to ensure we have no case
>> of mistaken identity? Or does that end up being problematic?
>
>
On Fri, Mar 16, 2012 at 8:14 AM, Daniel Farina wrote:
> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> outright kill a backend that they own (politely, with a SIGTERM),
> aborting any transactions in progress, including the idle transaction,
> and closing the socket.
+1
Parallel to pg_cancel_backend, it'd be nice to allow the user to just
outright kill a backend that they own (politely, with a SIGTERM),
aborting any transactions in progress, including the idle transaction,
and closing the socket.
I imagine the problem is a race condition whereby a pid might be
re
19 matches
Mail list logo
