Re: Hot standby, recovery infra
От | Heikki Linnakangas |
---|---|
Тема | Re: Hot standby, recovery infra |
Дата | |
Msg-id | 4984B776.4050807@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Hot standby, recovery infra (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Hot standby, recovery infra
|
Список | pgsql-hackers |
Simon Riggs wrote: > On Fri, 2009-01-30 at 16:55 +0200, Heikki Linnakangas wrote: >> Ok, here's an attempt to make shutdown work gracefully. >> >> Startup process now signals postmaster three times during startup: first >> when it has done all the initialization, and starts redo. At that point. >> postmaster launches bgwriter, which starts to perform restartpoints when >> it deems appropriate. The 2nd time signals when we've reached consistent >> recovery state. As the patch stands, that's not significant, but it will >> be with all the rest of the hot standby stuff. The 3rd signal is sent >> when startup process has finished recovery. Postmaster used to wait for >> the startup process to exit, and check the return code to determine >> that, but now that we support shutdown, startup process also returns >> with 0 exit code when it has been requested to terminate. > > Yeh, seems much cleaner. > > Slightly bizarre though cos now we're pretty much back to my originally > proposed design. C'est la vie. Yep. I didn't see any objections to that approach in the archives. There was other problems in the early versions of the patch, but nothing related to this arrangement. > I like this way because it means we might in the future get Startup > process to perform post-recovery actions also. Yeah, it does. Do you have something in mind already? > Your call to PMSIGNAL_RECOVERY_COMPLETED needs to be if > (IsUnderPostmaster), or at least a comment to explain why not or perhaps > an Assert. Nah, StartupProcessMain is only run under postmaster; you don't want to install signal handlers in a stand-along backend. Stand-alone backend calls StartupXLOG directly. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: