Re: Hot standby, recovery infra
От | Simon Riggs |
---|---|
Тема | Re: Hot standby, recovery infra |
Дата | |
Msg-id | 1233908234.4500.653.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Hot standby, recovery infra (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Hot standby, recovery infra
|
Список | pgsql-hackers |
On Fri, 2009-02-06 at 10:06 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Thu, 2009-02-05 at 21:54 +0200, Heikki Linnakangas wrote: > >> - If you perform a fast shutdown while startup process is waiting for > >> the restore command, startup process sometimes throws a FATAL error > >> which leads escalates into an immediate shutdown. That leads to > >> different messages in the logs, and skipping of the shutdown > >> restartpoint that we now otherwise perform. > > > > Sometimes? > > I think what happens is that if the restore command receives the SIGTERM > and dies before the startup process that's waiting for the restore > command receives the SIGTERM, the startup process throws a FATAL error > because the restore command died unexpectedly. I put this > > > if (shutdown_requested && InRedo) > > { > > /* XXX: Is EndRecPtr always the right value here? */ > > UpdateMinRecoveryPoint(EndRecPtr); > > proc_exit(0); > > } > > right after the "system(xlogRestoreCmd)" call, to exit gracefully if we > were requested to shut down while restore command was running, but it > seems that that's not enough because of the race condition. Can we trap the death of the restorecmd and handle it differently from the death of the startup process? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: