Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Point in Time Recovery

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Point in Time Recovery
Date: 2004-07-17 20:15:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-07-17 20:36:09
Subject: Why we really need timelines *now* in PITR
Previous:From: Jonathan M. GardnerDate: 2004-07-17 19:20:27
Subject: Fun with nested transactions in PL/pgSQL

pgsql-admin by date

Next:From: Tom LaneDate: 2004-07-17 21:18:16
Subject: Re: Migrate postgres databases from SQL_ASCII to UNICODE encoding
Previous:From: Dario V. FassiDate: 2004-07-17 20:03:31
Subject: Migrate postgres databases from SQL_ASCII to UNICODE encoding

pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-07-18 00:03:24
Subject: Re: Re : Win32 binaries test / pg_dump problem
Previous:From: Andreas PflugDate: 2004-07-17 19:56:34
Subject: logfile subprocess and Fancy File Functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group