Re: [HACKERS] Point in Time Recovery
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Point in Time Recovery |
Дата | |
Msg-id | 200407172015.i6HKFLK17349@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Point in Time Recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Point in Time Recovery
|
Список | pgsql-patches |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> What is the point of having both archive_program and archive_dest as > >> GUC variables? > > > I assume archive_dest is used for both archive and recovery of archives. > > You assume wrong; it's not used there. There isn't any real good > reason to suppose that the recovery process is going to fetch the files > from exactly where archiving put them, anyhow. > > > I think the idea is that you would turn archiving on and off regularly > > Why in the world would you do that? People who want PITR at all will > want it 24x7. > > > while you might never change the archive_command value. Also, how would > > you disable it? Set it to "", and if you do, you then have not way to > > remember your command string when you want to re-enable it. > > Leave the original value in a comment, if you're going to want it again > later. > > I don't think any of the above arguments outweigh the risk of people > shooting themselves in the foot by enabling archive_mode without > specifying a proper command/destination. So you want to merge them all into a single command string. That does seem less error-prone. I see a few variables that turn off when set to '' like unix_socket_*. How would this command string work? How do you specify the WAL file name to transfer? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: