Re: [PATCHES] Cancel/Kill backend functions -- docs
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
Re: [PATCHES] Cancel/Kill backend functions -- docs
Here's at least some documentation about these. Not sure if we want to refer to these somewhere else as well, but this gives them entries in misc functions. I don't have a working SGML build environment, so I'm not sure if this will turn out the way it's supposed (or even work at all). I tried 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 backend functions Patch applied. Thanks. Not sure where to document them. I think we talked about this already. I updated the system catalog version. --- signal_funcs_doc.patch Description: signal_funcs_doc.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
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. --- Magnus Hagander wrote: 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 resumbit this as a context diff? --- Magnus Hagander wrote: Okay, here is an updated patch. now uses IsBackendPid(), which is closely modeled (read cut-and-pasted) from TransactionIdIsInProgress(). Since it's no longer a pgstat function, I moved it to misc.c. Not 100% that's the right place either, but it seemed like the best alternative. //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 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 information, which is stored in shared memory. Consider TransactionIdIsInProgress() for an example. -Neil Content-Description: termbackend.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Content-Description: termbackend2.patch [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Cancel/Kill backend functions
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 resumbit this as a context diff? --- Magnus Hagander wrote: Okay, here is an updated patch. now uses IsBackendPid(), which is closely modeled (read cut-and-pasted) from TransactionIdIsInProgress(). Since it's no longer a pgstat function, I moved it to misc.c. Not 100% that's the right place either, but it seemed like the best alternative. //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 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 information, which is stored in shared memory. Consider TransactionIdIsInProgress() for an example. -Neil Content-Description: termbackend.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 termbackend2.patch Description: termbackend2.patch ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Cancel/Kill backend functions
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 IsBackendPid() test and terminates just before the kill() signal? It should be pretty unlikely but you could signal the wrong process ... shouldn't the SInvalLock be held throughout the whole operation? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) El número de instalaciones de UNIX se ha elevado a 10, y se espera que este número aumente (UPM, 1972) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Cancel/Kill backend functions
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 you could signal the wrong process ... shouldn't the SInvalLock be held throughout the whole operation? You'd actually need to get a pid *reuse* during that short time. Otherwise, you're just kill():ing a nonexistant process, which should be no problem. This is the same as issuing a kill -INT pid from the shell after doing ps(1), which is basically what this function tries to emulate. Should be no more dangerous than that. Bottom line - while maybe slightly more correcet, not sure it's necessary. //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Cancel/Kill backend functions
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 - while maybe slightly more correcet, not sure it's necessary. IMHO it's worth doing. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Cancel/Kill backend functions
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 remove the race condition, but it makes it less likely to occur for essentially very little cost. Other than holding a fairly critical lock for an operation that will take an unknown amount of time. 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 the SInvalLock is share-locked. pg_subtrans may need to do some I/O to get the data, and there could be multiple queries, depending on the nesting level. 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. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Bob [Floyd] used to say that he was planning to get a Ph.D. by the green stamp method, namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Cancel/Kill backend functions
Magnus, would you please resumbit this as a context diff? --- Magnus Hagander wrote: Okay, here is an updated patch. now uses IsBackendPid(), which is closely modeled (read cut-and-pasted) from TransactionIdIsInProgress(). Since it's no longer a pgstat function, I moved it to misc.c. Not 100% that's the right place either, but it seemed like the best alternative. //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 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 information, which is stored in shared memory. Consider TransactionIdIsInProgress() for an example. -Neil Content-Description: termbackend.patch [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Cancel/Kill backend functions
Okay, here is an updated patch. now uses IsBackendPid(), which is closely modeled (read cut-and-pasted) from TransactionIdIsInProgress(). Since it's no longer a pgstat function, I moved it to misc.c. Not 100% that's the right place either, but it seemed like the best alternative. //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 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 information, which is stored in shared memory. Consider TransactionIdIsInProgress() for an example. -Neil termbackend.patch Description: termbackend.patch ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Cancel/Kill backend functions
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 information, which is stored in shared memory. Consider TransactionIdIsInProgress() for an example. I guess the main reason is that I didn't find how to do it. With that pointer, I can probably redo it. 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? But I could certainly give it a try to recode it on that code. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Cancel/Kill backend functions
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 code that may not be running, when there's no need. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Cancel/Kill backend functions
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 able to do it remotely. Now that I think of it, there are probably a bunch of times when you can see the process information with ps but can't kill(1) it. With this point and others, I will update the patch to use the other method to determine if a PID is actualy a backend. //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
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). Why does this depend on pgstat? ISTM it would be better to use the per-backend PGPROC information, which is stored in shared memory. Consider TransactionIdIsInProgress() for an example. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Cancel/Kill backend functions
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 Managing Connections under Server Administration seems like perhaps a good place to put it, but might be overkill? //Magnus termbackend.patch Description: termbackend.patch ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
