pgman wrote:
> Josh Berkus wrote:
> > Tom,
> > 
> > > I don't think it's an open-and-shut decision as to whether people
> > > actually *need* to do session kills (as opposed to query/transaction
> > > kills).  The arguments presented so far are not convincing to my mind,
> > > certainly not convincing enough to buy into a commitment to do whatever
> > > it takes to support that.
> > 
> > Hmmm ... well, I can make a real-world case from my supported apps for 
> > transaction/statement kills.   But my support for session kills is just 
> > hypothetical; any  time I've had to kill off sessions, it's because I had to 
> > shut the database down, and that's better done from the command line.
> > 
> > My web apps which need to manage the number of connections do it through their 
> > connection pool.
> > 
> > So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom 
> > thinks there will be any significant support & troubleshooting involved for 
> > the latter.
> > 
> > Unless, of course, someone can give us a real business case that they have 
> > actually encountered in production.
> 
> Someone already posted some pseudocode where they wanted to kill idle
> backends, perhaps as part of connection pooling.

Tom, if you have concerns about SIGTERM while other backends keep
running, would you share those.  (Holding locks, shared memory?)  I
looked at die(), and it seemed pretty safe to me.  It just sets some
variables and returns.  It is not like quickdie that calls exit().

If there is a problem, maybe we can fix it, or perhap have the kill
function use SIGINT, then wait for the query to cancel, then SIGTERM.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 6 Apr 2004 14:38:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Function to kill backend
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If there is a problem, maybe we can fix it, or perhap have the kill
> function use SIGINT, then wait for the query to cancel, then SIGTERM.

Well, if someone could prove that the SIGTERM path is equivalent to
a transaction-aborting error followed by normal client disconnect,
I'd feel a lot better about its reliability.  We know those two code
paths work well.

Right now I do not think they are equivalent, but maybe they could be
made so.

			regards, tom lane

Tue, 06 Apr 2004 15:34:57 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function to kill backend 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If there is a problem, maybe we can fix it, or perhap have the kill
> > function use SIGINT, then wait for the query to cancel, then SIGTERM.
> 
> Well, if someone could prove that the SIGTERM path is equivalent to
> a transaction-aborting error followed by normal client disconnect,
> I'd feel a lot better about its reliability.  We know those two code
> paths work well.

As far as I know, most database systems have the ability to kill an
individual session, and I think we need that functionality too, as I
described in my report example.

> Right now I do not think they are equivalent, but maybe they could be
> made so.

Let me look into it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 6 Apr 2004 15:37:37 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Function to kill backend
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If there is a problem, maybe we can fix it, or perhap have the kill
> > function use SIGINT, then wait for the query to cancel, then SIGTERM.
> 
> Well, if someone could prove that the SIGTERM path is equivalent to
> a transaction-aborting error followed by normal client disconnect,
> I'd feel a lot better about its reliability.  We know those two code
> paths work well.
> 
> Right now I do not think they are equivalent, but maybe they could be
> made so.

I just did a whitespace-ignore diff of the SIGINT (which is cancel and
we know works), and SIGTERM (which is under study).  Here is a diff of
SIGINT vs. SIGTERM functions:

	1,2c1,2
	< static void
	< StatementCancelHandler(SIGNAL_ARGS)
	---
	> void
	> die(SIGNAL_ARGS)
	6,10c6,7
	<   /*
	<    * Don't joggle the elbow of proc_exit, nor an already-in-progress
	<    * abort
	<    */
	<   if (!proc_exit_inprogress && !InError)
	---
	>   /* Don't joggle the elbow of proc_exit */
	>   if (!proc_exit_inprogress)
	13c10
	<       QueryCancelPending = true;
	---
	>       ProcDiePending = true;
	16,18c13,14
	<        * If it's safe to interrupt, and we're waiting for a lock,
	<        * service the interrupt immediately.  No point in interrupting if
	<        * we're waiting for input, however.
	---
	>        * If it's safe to interrupt, and we're waiting for input or a
	>        * lock, service the interrupt immediately
	26,33c22,26
	<           if (LockWaitCancel())
	<           {
	<               DisableNotifyInterrupt();
	<               InterruptHoldoffCount--;
	<               ProcessInterrupts();
	<           }
	<           else
	<               InterruptHoldoffCount--;
	---
	>           DisableNotifyInterrupt();
	>           /* Make sure CheckDeadLock won't run while shutting down... */
	>           LockWaitCancel();
	>           InterruptHoldoffCount--;
	>           ProcessInterrupts();

The big difference seems to be the InError test, and the test in SIGINT
whether LockWaitCancel() actually returns true or false.  Also,
DisableNotifyInterrupt() is called before LockWaitCancel().

Also, one sets QueryCancelPending and the other ProcDiePending.  Those
are handled by:
	
	void
	ProcessInterrupts(void)
	{
	    /* OK to accept interrupt now? */
	    if (InterruptHoldoffCount != 0 || CritSectionCount != 0)
	        return;
	    InterruptPending = false;
	    if (ProcDiePending)
	    {
	        ProcDiePending = false;
	        QueryCancelPending = false;     /* ProcDie trumps QueryCancel */
	        ImmediateInterruptOK = false;   /* not idle anymore */
	        DisableNotifyInterrupt();
	        ereport(FATAL,
	                (errcode(ERRCODE_ADMIN_SHUTDOWN),
	         errmsg("terminating connection due to administrator command")));
	    }
	    if (QueryCancelPending)
	    {
	        QueryCancelPending = false;
	        ImmediateInterruptOK = false;   /* not idle anymore */
	        DisableNotifyInterrupt();
	        ereport(ERROR,
	                (errcode(ERRCODE_QUERY_CANCELED),
	                 errmsg("canceling query due to user request")));
	    }
	    /* If we get here, do nothing (probably, QueryCancelPending was reset) */
	}

and the only difference here seems to be the elog(SHUTDOWN) call.

On first glance, I don't see anything dangerous about SIGTERM.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 6 Apr 2004 16:15:23 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Function to kill backend
Bruce Momjian wrote:

>pgman wrote:
>  
>
>>Josh Berkus wrote:
>>    
>>
>>>Tom,
>>>
>>>      
>>>
>>>>I don't think it's an open-and-shut decision as to whether people
>>>>actually *need* to do session kills (as opposed to query/transaction
>>>>kills).  The arguments presented so far are not convincing to my mind,
>>>>certainly not convincing enough to buy into a commitment to do whatever
>>>>it takes to support that.
>>>>        
>>>>
>>>Hmmm ... well, I can make a real-world case from my supported apps for 
>>>transaction/statement kills.   But my support for session kills is just 
>>>hypothetical; any  time I've had to kill off sessions, it's because I had to 
>>>shut the database down, and that's better done from the command line.
>>>
>>>My web apps which need to manage the number of connections do it through their 
>>>connection pool.
>>>
>>>So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom 
>>>thinks there will be any significant support & troubleshooting involved for 
>>>the latter.
>>>
>>>Unless, of course, someone can give us a real business case that they have 
>>>actually encountered in production.
>>>      
>>>
>>Someone already posted some pseudocode where they wanted to kill idle
>>backends, perhaps as part of connection pooling.
>>    
>>
>
>Tom, if you have concerns about SIGTERM while other backends keep
>running, would you share those.  (Holding locks, shared memory?)  I
>looked at die(), and it seemed pretty safe to me.  It just sets some
>variables and returns.  It is not like quickdie that calls exit().
>
>If there is a problem, maybe we can fix it, or perhap have the kill
>function use SIGINT, then wait for the query to cancel, then SIGTERM.
>
>  
>
One other option to consider while your looking at killing off children
as an admin is the ability to switch the database to single user mode
for the admin via psql or other connection interface.   In essence
shutdown all other transactions and session and limit it to only one so
that maintenance issues (reindexing, etc) can be done remotely and do
not require shell access on the host machine.

I think, ultimately, this may be what is being asked for:  a way to
manage postgresql internally via SQL or other functions rather than
relying on user access to the machine (ie sending signals to
processes).   This is what some people have wanted to do with managing
the connection settings in pg_hba.conf via a system table rather than or
in addition to a file.


Tue, 06 Apr 2004 20:44:58 -0500
Thomas Swan <tswan@idigx.com>
Re: Function to kill backend
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> On first glance, I don't see anything dangerous about SIGTERM.

You haven't thought about it very hard :-(

The major difference I see is that elog(FATAL) will call proc_exit
directly from elog, rather than longjmp'ing back to PostgresMain.
The case that we have confidence in involves elog(ERROR) returning to
PostgresMain and then calling proc_exit from there (in the path where
we get EOF from the client).

This leaves me with a couple of concerns:

* Notice all that cleanup/reset stuff in the "if (sigsetjmp())" block
in PostgresMain.  SIGTERM will cause proc_exit to be entered without
any of that being done first.  Does it work reliably?  Shouldn't this be
refactored to ensure the same things happen in both cases?

* There are various places, especially in the PLs, that try to hook into
error recovery by manipulating Warn_restart.  Will any of them have
problems if their error recovery code doesn't get called during SIGTERM
exit?

One possible refactoring is for elog(FATAL) to go ahead and longjmp back
to PostgresMain, and at the end of the error recovery block check a flag
and do proc_exit() if we're fataling.  However I am not sure that this
doesn't break the design for coping with elog's during proc_exit.

Alvaro's nested-transaction work is another thing that's got to be
thought about before touching this code.  I have not yet seen any design
for error recovery in the nested xact case, but I am sure it's going to
need some changes right around here.

			regards, tom lane

Thu, 08 Apr 2004 12:47:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function to kill backend 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > On first glance, I don't see anything dangerous about SIGTERM.
> 
> You haven't thought about it very hard :-(

Yea, that's why I said "on first glance".

> The major difference I see is that elog(FATAL) will call proc_exit
> directly from elog, rather than longjmp'ing back to PostgresMain.
> The case that we have confidence in involves elog(ERROR) returning to
> PostgresMain and then calling proc_exit from there (in the path where
> we get EOF from the client).
> 
> This leaves me with a couple of concerns:
> 
> * Notice all that cleanup/reset stuff in the "if (sigsetjmp())" block
> in PostgresMain.  SIGTERM will cause proc_exit to be entered without
> any of that being done first.  Does it work reliably?  Shouldn't this be
> refactored to ensure the same things happen in both cases?
> 
> * There are various places, especially in the PLs, that try to hook into
> error recovery by manipulating Warn_restart.  Will any of them have
> problems if their error recovery code doesn't get called during SIGTERM
> exit?
> 
> One possible refactoring is for elog(FATAL) to go ahead and longjmp back
> to PostgresMain, and at the end of the error recovery block check a flag
> and do proc_exit() if we're fataling.  However I am not sure that this
> doesn't break the design for coping with elog's during proc_exit.
> 
> Alvaro's nested-transaction work is another thing that's got to be
> thought about before touching this code.  I have not yet seen any design
> for error recovery in the nested xact case, but I am sure it's going to
> need some changes right around here.

OK, the attached patch refactors the elog(FATAL)/SIGTERM exit to behave
just like a EOF from the client, with the exception of sending a proper
exit code.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: src/backend/tcop/postgres.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.398
diff -c -c -r1.398 postgres.c
*** src/backend/tcop/postgres.c	7 Apr 2004 05:05:49 -0000	1.398
--- src/backend/tcop/postgres.c	8 Apr 2004 18:59:33 -0000
***************
*** 2938,2944 ****
  		/*
  		 * (3) read a command (loop blocks here)
  		 */
! 		firstchar = ReadCommand(&input_message);
  
  		/*
  		 * (4) disable async signal conditions again.
--- 2938,2947 ----
  		/*
  		 * (3) read a command (loop blocks here)
  		 */
! 		 if (!in_fatal_exit)
! 			firstchar = ReadCommand(&input_message);
! 		else
! 			firstchar = EOF;
  
  		/*
  		 * (4) disable async signal conditions again.
***************
*** 3170,3176 ****
  				 * Otherwise it will fail to be called during other
  				 * backend-shutdown scenarios.
  				 */
! 				proc_exit(0);
  
  			case 'd':			/* copy data */
  			case 'c':			/* copy done */
--- 3173,3180 ----
  				 * Otherwise it will fail to be called during other
  				 * backend-shutdown scenarios.
  				 */
! 				proc_exit(!in_fatal_exit ? 0 : proc_exit_inprogress ||
! 												!IsUnderPostmaster);
  
  			case 'd':			/* copy data */
  			case 'c':			/* copy done */
Index: src/backend/utils/error/elog.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/error/elog.c,v
retrieving revision 1.132
diff -c -c -r1.132 elog.c
*** src/backend/utils/error/elog.c	5 Apr 2004 03:02:06 -0000	1.132
--- src/backend/utils/error/elog.c	8 Apr 2004 18:59:34 -0000
***************
*** 72,77 ****
--- 72,79 ----
  char       *Log_line_prefix = NULL; /* format for extra log line info */
  unsigned int Log_destination;
  
+ bool in_fatal_exit = false;
+ 
  #ifdef HAVE_SYSLOG
  char	   *Syslog_facility;	/* openlog() parameters */
  char	   *Syslog_ident;
***************
*** 442,448 ****
  			 */
  			fflush(stdout);
  			fflush(stderr);
! 			proc_exit(proc_exit_inprogress || !IsUnderPostmaster);
  		}
  
  		/*
--- 444,453 ----
  			 */
  			fflush(stdout);
  			fflush(stderr);
! 
! 			if (in_fatal_exit)
! 				ereport(PANIC, (errmsg("fatal error during fatal exit, giving up")));
! 			in_fatal_exit = true;
  		}
  
  		/*
Index: src/include/tcop/tcopprot.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/tcop/tcopprot.h,v
retrieving revision 1.64
diff -c -c -r1.64 tcopprot.h
*** src/include/tcop/tcopprot.h	7 Apr 2004 05:05:50 -0000	1.64
--- src/include/tcop/tcopprot.h	8 Apr 2004 18:59:36 -0000
***************
*** 34,39 ****
--- 34,40 ----
  extern DLLIMPORT const char *debug_query_string;
  extern char *rendezvous_name;
  extern int	max_stack_depth;
+ extern bool in_fatal_exit;
  
  /* GUC-configurable parameters */
Thu, 8 Apr 2004 15:04:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Function to kill backend
I have applied the attached patch:

   Exit backend from SIGTERM or FATAL by simulating client EOF, rather than
   calling proc_exit() directly.  This should make SIGTERM more reliable.


---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > On first glance, I don't see anything dangerous about SIGTERM.
> 
> You haven't thought about it very hard :-(
> 
> The major difference I see is that elog(FATAL) will call proc_exit
> directly from elog, rather than longjmp'ing back to PostgresMain.
> The case that we have confidence in involves elog(ERROR) returning to
> PostgresMain and then calling proc_exit from there (in the path where
> we get EOF from the client).
> 
> This leaves me with a couple of concerns:
> 
> * Notice all that cleanup/reset stuff in the "if (sigsetjmp())" block
> in PostgresMain.  SIGTERM will cause proc_exit to be entered without
> any of that being done first.  Does it work reliably?  Shouldn't this be
> refactored to ensure the same things happen in both cases?
> 
> * There are various places, especially in the PLs, that try to hook into
> error recovery by manipulating Warn_restart.  Will any of them have
> problems if their error recovery code doesn't get called during SIGTERM
> exit?
> 
> One possible refactoring is for elog(FATAL) to go ahead and longjmp back
> to PostgresMain, and at the end of the error recovery block check a flag
> and do proc_exit() if we're fataling.  However I am not sure that this
> doesn't break the design for coping with elog's during proc_exit.
> 
> Alvaro's nested-transaction work is another thing that's got to be
> thought about before touching this code.  I have not yet seen any design
> for error recovery in the nested xact case, but I am sure it's going to
> need some changes right around here.
> 
> 			regards, tom lane
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: src/backend/tcop/postgres.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.398
diff -c -c -r1.398 postgres.c
*** src/backend/tcop/postgres.c	7 Apr 2004 05:05:49 -0000	1.398
--- src/backend/tcop/postgres.c	9 Apr 2004 17:42:46 -0000
***************
*** 2938,2944 ****
  		/*
  		 * (3) read a command (loop blocks here)
  		 */
! 		firstchar = ReadCommand(&input_message);
  
  		/*
  		 * (4) disable async signal conditions again.
--- 2938,2947 ----
  		/*
  		 * (3) read a command (loop blocks here)
  		 */
! 		 if (!in_fatal_exit)
! 			firstchar = ReadCommand(&input_message);
! 		else
! 			firstchar = EOF;
  
  		/*
  		 * (4) disable async signal conditions again.
***************
*** 3170,3176 ****
  				 * Otherwise it will fail to be called during other
  				 * backend-shutdown scenarios.
  				 */
! 				proc_exit(0);
  
  			case 'd':			/* copy data */
  			case 'c':			/* copy done */
--- 3173,3180 ----
  				 * Otherwise it will fail to be called during other
  				 * backend-shutdown scenarios.
  				 */
! 				proc_exit(!in_fatal_exit ? 0 : proc_exit_inprogress ||
! 												!IsUnderPostmaster);
  
  			case 'd':			/* copy data */
  			case 'c':			/* copy done */
Index: src/backend/utils/error/elog.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/utils/error/elog.c,v
retrieving revision 1.132
diff -c -c -r1.132 elog.c
*** src/backend/utils/error/elog.c	5 Apr 2004 03:02:06 -0000	1.132
--- src/backend/utils/error/elog.c	9 Apr 2004 17:42:47 -0000
***************
*** 72,77 ****
--- 72,79 ----
  char       *Log_line_prefix = NULL; /* format for extra log line info */
  unsigned int Log_destination;
  
+ bool in_fatal_exit = false;
+ 
  #ifdef HAVE_SYSLOG
  char	   *Syslog_facility;	/* openlog() parameters */
  char	   *Syslog_ident;
***************
*** 442,448 ****
  			 */
  			fflush(stdout);
  			fflush(stderr);
! 			proc_exit(proc_exit_inprogress || !IsUnderPostmaster);
  		}
  
  		/*
--- 444,455 ----
  			 */
  			fflush(stdout);
  			fflush(stderr);
! 
! 			if (in_fatal_exit)
! 				ereport(PANIC, (errmsg("fatal error during fatal exit, giving up")));
! 
! 			/* We will exit the backend by simulating a client EOF */
! 			in_fatal_exit = true;
  		}
  
  		/*
Index: src/include/tcop/tcopprot.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/tcop/tcopprot.h,v
retrieving revision 1.64
diff -c -c -r1.64 tcopprot.h
*** src/include/tcop/tcopprot.h	7 Apr 2004 05:05:50 -0000	1.64
--- src/include/tcop/tcopprot.h	9 Apr 2004 17:42:47 -0000
***************
*** 34,39 ****
--- 34,40 ----
  extern DLLIMPORT const char *debug_query_string;
  extern char *rendezvous_name;
  extern int	max_stack_depth;
+ extern bool in_fatal_exit;
  
  /* GUC-configurable parameters */
Sat, 10 Apr 2004 21:00:28 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Function to kill backend
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I have applied the attached patch:
>    Exit backend from SIGTERM or FATAL by simulating client EOF, rather than
>    calling proc_exit() directly.  This should make SIGTERM more reliable.

After further consideration I have concluded that this was a
spectacularly bad idea and we should revert that patch.  There is a very
large amount of processing that this patch will cause to happen after a
FATAL error has been declared, and I doubt that any of it is a good
idea.  Some examples:

* AbortCurrentTransaction() --- not too cool if the FATAL error was one
  of the ones in xact.c that are complaining of fatally bollixed
  transaction state.

* pgstat reporting --- aside from the chance of an outright crash, we
  might be transmitting bogus statistics to the collector.

* sending a ReadyForQuery (Z) message --- one thing we quite certainly
  ain't is ReadyForQuery.

* EnableNotifyInterrupt --- this may result in actually trying to run
  a transaction to look through pg_listener :-(

* ProcessConfigFile, if we had a pending SIGHUP --- also not too cool,
  if the FATAL was from guc.c.


I am still dubious that zapping random backends with SIGTERM is a sane
or supportable idea.  But this patch does not make things better, it
simply greatly increases the chance of a FATAL exit turning into a
backend crash or PANIC.

			regards, tom lane

Sat, 24 Jul 2004 16:35:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Function to kill backend 

OK, I see your point.  Can anyone remember why this was needed?  I
remember Magnus wanted query cancel, but what was the logic for session
termination?

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have applied the attached patch:
> >    Exit backend from SIGTERM or FATAL by simulating client EOF, rather than
> >    calling proc_exit() directly.  This should make SIGTERM more reliable.
> 
> After further consideration I have concluded that this was a
> spectacularly bad idea and we should revert that patch.  There is a very
> large amount of processing that this patch will cause to happen after a
> FATAL error has been declared, and I doubt that any of it is a good
> idea.  Some examples:
> 
> * AbortCurrentTransaction() --- not too cool if the FATAL error was one
>   of the ones in xact.c that are complaining of fatally bollixed
>   transaction state.
> 
> * pgstat reporting --- aside from the chance of an outright crash, we
>   might be transmitting bogus statistics to the collector.
> 
> * sending a ReadyForQuery (Z) message --- one thing we quite certainly
>   ain't is ReadyForQuery.
> 
> * EnableNotifyInterrupt --- this may result in actually trying to run
>   a transaction to look through pg_listener :-(
> 
> * ProcessConfigFile, if we had a pending SIGHUP --- also not too cool,
>   if the FATAL was from guc.c.
> 
> 
> I am still dubious that zapping random backends with SIGTERM is a sane
> or supportable idea.  But this patch does not make things better, it
> simply greatly increases the chance of a FATAL exit turning into a
> backend crash or PANIC.
> 
> 			regards, tom lane
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 24 Jul 2004 17:44:14 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Function to kill backend
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I see your point.  Can anyone remember why this was needed?  I
> remember Magnus wanted query cancel, but what was the logic for session
> termination?

I think the argument for it went along the lines of "what if you've got
a misbehaving client that continually issues expensive queries, so
canceling any one query doesn't help?"  I found this unconvincing, as
a client that obstreperous might simply reconnect and start issuing the
same queries again; so having a session-kill tool doesn't really get you
much further.  I recall being voted down though ...

			regards, tom lane

Sat, 24 Jul 2004 18:51:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Function to kill backend 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, I see your point.  Can anyone remember why this was needed?  I
> > remember Magnus wanted query cancel, but what was the logic for session
> > termination?
> 
> I think the argument for it went along the lines of "what if you've got
> a misbehaving client that continually issues expensive queries, so
> canceling any one query doesn't help?"  I found this unconvincing, as
> a client that obstreperous might simply reconnect and start issuing the
> same queries again; so having a session-kill tool doesn't really get you
> much further.  I recall being voted down though ...

Well, seems you have enough reason to suspect this code, and being so
near to beta I think we can remove it and come back to it later if
people still want it.  I remember the "cancel" being the key feature,
and termination was more of a "nice have" item.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 24 Jul 2004 18:55:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Function to kill backend