Thread: Shutdown term
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
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/
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
> 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
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
> 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