From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Point in Time Recovery |
Date: | 2004-07-18 20:20:52 |
Message-ID: | 1090182052.17493.18904.camel@stromboli |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers pgsql-patches |
On Sun, 2004-07-18 at 06:04, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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?
>
GUC-wise, I implemented what we agreed in discussions...
There are many things in need of refactoring, so my focus was on
delivering what we agreed, even knowing it would probably change...
A few notes on the patch (as I submitted it - so as not to confuse with
other versions being worked upon)
- archive_dest is definitely used in both archive and recovery. There
wasn't much need for this GUC apart from that and I think we are better
off without it. Removing it improves recovery flexibility (we cannot
assume the recovery is taking place in anything like the original
configuration).
- archive_mode I would prefer to keep - it is explicit then which mode
you are in, rather than implicit from the command string. In all other
ways I agree with everything Tom has said. It allows us to talk about
"being in archive_mode" without people saying "but I can't work out how
to turn archive mode on".
When archiver starts the FIRST thing it does is run a test to confirm
that the command string works, so setting archive_command to '' would
simply generate an error.
Also, I would suggest this:
- changing archive mode requires a postmaster restart
- changing archive command should just be a SIGHUP...we don't want to
force a restart just to switch to a new kind of archiving
If you can only change archive_program at postmaster start that is
restrictive, but making that SIGHUP would allow people to set it to ''
and turn off archiving while postmaster is up == lurking fault.
> No different from before, necessarily. However I did not like the
> restriction to a single %s in the submitted implementation. What I
> have in my local copy is
> %p -> full path of XLOG file to be archived
> %f -> base name of XLOG file to be archived
> and the suggested example becomes
> archive_command = 'cp %p /mnt/server/pgarchive/%f'
>
I'm happy with those changes and would have done them myself given
time... the 2 or 3 %s parameters wasn't the most user friendly way of
doing it.
> Note that this example immediately eliminates one of the failure modes
> Simon enumerates in his README, which is to try 'cp %s /foo' where /foo
> isn't a directory. More generally, though, *only* a cp-to-directory
> solution is likely to be very happy with not being able to get at the
> base file name. Yes you can make a shellscript and use basename,
> but I don't think you should have to do that if it could otherwise
> be a one-liner.
>
Good.
> (In case it's not obvious from the above, I am hacking with intent to
> commit soon. Maybe tomorrow, if my wife doesn't make me paint the
> bathroom instead...)
>
...just returned from there... :)
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2004-07-18 20:41:51 | Re: How do I grant access to entire database at |
Previous Message | Dario V. Fassi | 2004-07-18 20:01:08 | Re: ADMIN Migrate postgres databases from SQL_ASCII to UNICODE |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2004-07-18 21:08:09 | Re: Toward better documentation |
Previous Message | Peter Eisentraut | 2004-07-18 20:14:23 | Re: Toward better documentation |
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2004-07-18 22:20:10 | Re: logfile subprocess and Fancy File Functions |
Previous Message | Mark Kirkwood | 2004-07-18 08:05:42 | Re: PITR COPY Failure (was Point in Time Recovery) |