Re: smart shutdown at end of transaction (was: Default mode for shutdown)
От | Robert Haas |
---|---|
Тема | Re: smart shutdown at end of transaction (was: Default mode for shutdown) |
Дата | |
Msg-id | CA+TgmoZpm9-gByG1009X9VHGaCQsR6cF45hTAHr7eA-BhMCC5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: smart shutdown at end of transaction (was: Default mode for shutdown) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: smart shutdown at end of transaction (was: Default mode for shutdown)
|
Список | pgsql-hackers |
On Fri, Apr 27, 2012 at 3:00 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm not necessarily opposed to commandeering the name "smart" for the >> new behavior, so that what we have to find a name for is the old "smart" >> behavior. How about >> >> slow - allow existing sessions to finish (old "smart") >> smart - allow existing transactions to finish (new) >> fast - kill active queries >> immediate - unclean shutdown > > I could live with that. Really, I'd like to have fast just be the > default. But the above compromise would still be a big improvement > over what we have now, assuming the new smart becomes the default. So right now, we have a mapping from signals to shutdown types that looks like this: [Current] SIGTERM -> smart, SIGINT -> fast, SIGQUIT -> immediate It seems we need another signal for the new mode, and the obvious candidate is SIGUSR2. But what shall the mapping look like? [Choice #1] SIGUSR2 -> slow, SIGTERM -> smart, SIGINT -> fast, SIGQUIT -> immediate [Choice #2] SIGTERM -> slow, SIGUSR2 -> smart, SIGINT -> fast, SIGQUIT -> immediate In other words, should we retain the existing behavior for SIGTERM and make SIGUSR2 have the new behavior (choice #2)? Or shall we preserve the invariant that SIGTERM invokes the default shutdown mode, and move the current default behavior off into SIGUSR2 land (choice #1)? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: