Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
От | Alvaro Herrera |
---|---|
Тема | Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks) |
Дата | |
Msg-id | 20130622172348.GB4051@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks) ("MauMau" <maumau307@gmail.com>) |
Ответы |
Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
|
Список | pgsql-hackers |
MauMau escribió: > Are you suggesting simplifying the following part in ServerLoop()? > I welcome the idea if this condition becomes simpler. However, I > cannot imagine how. > if (AbortStartTime > 0 && /* SIGKILL only once */ > (Shutdown == ImmediateShutdown || (FatalError && !SendStop)) && > now - AbortStartTime >= 10) > { > SignalAllChildren(SIGKILL); > AbortStartTime = 0; > } Yes, that's what I'm suggesting. I haven't tried coding it yet. > I thought of adding some new state of pmState for some reason (that > might be the same as your idea). > But I refrained from doing that, because pmState has already many > states. I was afraid adding a new pmState value for this bug fix > would complicate the state management (e.g. state transition in > PostmasterStateMachine()). In addition, I felt PM_WAIT_BACKENDS was > appropriate because postmaster is actually waiting for backends to > terminate after sending SIGQUIT. The state name is natural. Well, a natural state name is of no use if we're using it to indicate two different states, which I think is what would be happening here. Basically, with your patch, PM_WAIT_BACKENDS means two different things depending on AbortStartTime. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: