Re: [HACKERS] Point in Time Recovery - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: [HACKERS] Point in Time Recovery
Date
Msg-id 200407172015.i6HKFLK17349@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Point in Time Recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Point in Time Recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andreas Pflug
Date:
Subject: logfile subprocess and Fancy File Functions
Next
From: Andrew Dunstan
Date:
Subject: Re: [pgsql-hackers-win32] Re : Win32 binaries test / pg_dump problem