Magnus Hagander [EMAIL PROTECTED] writes:
Here's at least some documentation about these.
Applied.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
to
model it on stuff that's nearby. If not, let me know where I missed and
I'll update it.
//Magnus
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 2 juni 2004 23:30
To: Magnus Hagander
Cc: Neil Conway; [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 26 maj 2004 20:50
To: Magnus Hagander
Cc: Neil Conway; [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill backend functions
Magnus, would you please resumbit this as a context diff
Arrgh, when will I ever learn :-(
Attached.
//Magnus
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: den 26 maj 2004 20:50
To: Magnus Hagander
Cc: Neil Conway; [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill backend functions
Magnus, would you please
On Thu, May 27, 2004 at 08:08:34PM +0200, Magnus Hagander wrote:
Magnus Hagander wrote:
Okay, here is an updated patch. now uses IsBackendPid(), which is
closely modeled (read cut-and-pasted) from
TransactionIdIsInProgress().
I wonder what can happen if a backend passes the
Okay, here is an updated patch. now uses IsBackendPid(), which is
closely modeled (read cut-and-pasted) from
TransactionIdIsInProgress().
I wonder what can happen if a backend passes the
IsBackendPid() test and
terminates just before the kill() signal? It should be pretty unlikely
but
Magnus Hagander wrote:
You'd actually need to get a pid *reuse* during that short time.
That isn't so implausible on a system which assigns PIDs randomly.
Holding the SInvalLock doesn't remove the race condition, but it
makes it less likely to occur for essentially very little cost.
Bottom line
On Fri, May 28, 2004 at 01:01:10AM -0400, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
You'd actually need to get a pid *reuse* during that short time.
That isn't so implausible on a system which assigns PIDs randomly.
Holding the SInvalLock doesn't
PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill backend functions
Magnus Hagander wrote:
Per previous discussions, here are two functions to send INT and TERM
signals to other backends.They permit only INT and TERM, and permits
sending only to postgresql backends (as registered in pgstat
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: den 22 maj 2004 10:00
To: Magnus Hagander
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCHES] Cancel/Kill backend functions
Magnus Hagander wrote:
Per previous discussions, here are two functions to send INT and TERM
signals
Per previous discussions, here are two functions to send INT and TERM
signals to other backends.They permit only INT and TERM, and permits
sending only to postgresql backends (as registered in pgstat).
Why does this depend on pgstat? ISTM it would be better to use the
per-backend PGPROC
Magnus Hagander [EMAIL PROTECTED] writes:
The other thought is that you're not going to have much use of this if
you don't have pgstat anyway - how are you going to find out which
backends actually exist?
ps, perhaps? Anyway I agree with Neil that it'd be better not to have a
dependency on
The other thought is that you're not going to have much use
of this if
you don't have pgstat anyway - how are you going to find out which
backends actually exist?
Uh, what about ps(1)?
Well, if you ran run ps(1), then you can probably run kill(1) too. The
main point of this patch was to be
Magnus Hagander wrote:
Per previous discussions, here are two functions to send INT and TERM
signals to other backends.They permit only INT and TERM, and permits
sending only to postgresql backends (as registered in pgstat).
Why does this depend on pgstat? ISTM it would be better to use the
Per previous discussions, here are two functions to send INT and TERM
signals to other backends.They permit only INT and TERM, and permits
sending only to postgresql backends (as registered in pgstat).
Documentation to follow. I'd appreciate some pointers as to where to put
this. A new section
15 matches
Mail list logo
