"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
onway; [EMAIL PROTECTED]
>Subject: Re: [PATCHES] Cancel/Kill backend functions
>
>
>
>Patch applied. Thanks.
>
>Not sure where to document them. I think we talked about this already.
>
>I updated the system catalog version.
>
>--
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
&
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I could write it to save the xid's in PGPROC in a first pass, then
> release the SInvalLock, then look at pg_subtrans. But I think doing it
> this way has a ("is a?") race condition.
The way that would be technically correct is to *first* look in
pg_su
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> With this comment, I take it you'd disagree with my recoding of
> TransactionIdIsCurrentTransactionId().
> The current code has to scan only the xid's in each PGPROC struct.
> However I had to rewrite it to peek at pg_subtrans, and this is done
> while
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
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 remove the race condition, but it
> makes it less likely to o
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
>> >> 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
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 Is
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
>
&
IL 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 se
ternative.
//Magnus
>-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 dis
>> 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
"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
Magnus Hagander wrote:
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)?
-Neil
---(end of broadcast)---
TIP 2: you c
>> 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 PGPR
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-ba
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 "Ma
19 matches
Mail list logo
