Thread: Shutdown term

Shutdown term

From
Bruce Momjian
Date:
Can somone improve the wording?
The system is shutting down.

when the backend receives a SIGTERM.  Seems we need some wording that
can apply to db shutdown and individual backend termination by
administrators.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Shutdown term

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> Can somone improve the wording?
>
>     The system is shutting down.
>
> when the backend receives a SIGTERM.  Seems we need some wording that
> can apply to db shutdown and individual backend termination by
> administrators.
The connection was terminated.

And make the postmaster print out
The system is shutting down.

before it sends out the SIGTERM's.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: Shutdown term

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
>     The connection was terminated.
> And make the postmaster print out
>     The system is shutting down.
> before it sends out the SIGTERM's.

Unfortunately the postmaster is in no position to send any message to
the individual clients.

Maybe we should forget the idea of having a single message to cover
both cases, and instead provide some flag in shared memory that the
postmaster can set before it sends out SIGTERMs.  Then the backends
would actually know why they got a SIGTERM and could emit
more-appropriate messages.
        regards, tom lane


Re: Shutdown term

From
Bruce Momjian
Date:
> Peter Eisentraut <peter_e@gmx.net> writes:
> >     The connection was terminated.
> > And make the postmaster print out
> >     The system is shutting down.
> > before it sends out the SIGTERM's.
> 
> Unfortunately the postmaster is in no position to send any message to
> the individual clients.
> 
> Maybe we should forget the idea of having a single message to cover
> both cases, and instead provide some flag in shared memory that the
> postmaster can set before it sends out SIGTERMs.  Then the backends
> would actually know why they got a SIGTERM and could emit
> more-appropriate messages.

Seems like overkill to me.  We could have the postmaster use SIGQUIT for
db shutdown and leave SIGKILL for admin shutdown of individual backends.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Shutdown term

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Seems like overkill to me.  We could have the postmaster use SIGQUIT for
> db shutdown and leave SIGKILL for admin shutdown of individual backends.

Wrong... at least not with the current definitions of those signals!
        regards, tom lane


Re: Shutdown term

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Seems like overkill to me.  We could have the postmaster use SIGQUIT for
> > db shutdown and leave SIGKILL for admin shutdown of individual backends.
> 
> Wrong... at least not with the current definitions of those signals!

I see you just changed them today:
       pqsignal(SIGTERM, die);         /* cancel current query and exit */
!       pqsignal(SIGQUIT, quickdie); /* hard crash time */
!       pqsignal(SIGALRM, HandleDeadLock); /* check for deadlock after timeout *

How about:
The database is shutting down.

and not mention server.  The current 'system' has to be changed to
'database server' anyway.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026