Re: Simplifying "standby mode"
От | Bruce Momjian |
---|---|
Тема | Re: Simplifying "standby mode" |
Дата | |
Msg-id | 200609021314.k82DE6f09917@momjian.us обсуждение исходный текст |
Ответ на | Re: Simplifying "standby mode" (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Simplifying "standby mode"
|
Список | pgsql-hackers |
Simon Riggs wrote: > On Mon, 2006-08-07 at 11:37 -0400, Tom Lane wrote: > > Simon Riggs <simon@2ndquadrant.com> writes: > > > If we are in standby mode, then rather than ending recovery we go into a > > > wait loop. We poll for the next file, then sleep for 1000 ms, then poll > > > again. When a file arrives we mark a restartpoint each checkpoint. > > > > > We need the standby_mode to signify the difference in behaviour at > > > end-of-logs, but we may not need a parameter of that exact name. > > > > > The piece I have been puzzling over is how to initiate a failover when > > > in standby_mode. I've not come up with a better solution than checking > > > for the existence of a trigger file each time round the next-file wait > > > loop. This would use a naming convention to indicate the port number, > > > allowing us to uniquely identify a cluster on any single server. That's > > > about as portable and generic as you'll get. > > > > The original intention was that all this sort of logic was to be > > external in the recovery_command script. I'm pretty dubious about > > freezing it in the C code when there's not yet an established > > convention for how it should work. I'd kinda like to see a widely > > accepted recovery_command script before we move the logic inside > > the server. > > OK, I'll submit a C program called pg_standby so that we have an > approved and portable version of the script, allowing it to be > documented more easily. I think we are still waiting for this. I am also waiting for more PITR documentation to go with the recent patches. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: