On 03.05.2013 16:29, Bruce Momjian wrote:
On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote:
This changes the existing API which will confuse people that know it
and invalidate everything written in software and on wikis as to how
to do it. That means all the "in case of fire break glass"
instructions are all wrong and need to be rewritten and retested.
Yes, *that* is the main reason *not* to make the change. It has a
pretty bad cost in backwards compatibility loss. There is a gain, but
I don't think it outweighs the cost.
So, is there a way to add this feature without breaking the API?
Yes, by adding a new parameter exclusively used to control this feature,
something like recovery_target_immediate = 'on/off'.
We just need to add a named restore point when ending the backup (in
pg_stop_backup() ?).
No API change required. Just document that some predefined target names are set
during backup.
So we auto-add a restore point based on the backup label. Does that
work for everyone?
Unfortunately, no. There are cases where you want to stop right after
reaching consistency, but the point where you reach consistency is not
at the end of a backup. For example, if you take a backup using an
atomic filesystem snapshot, there are no pg_start/stop_backup calls, and
the system will reach consistency after replaying all the WAL in
pg_xlog. You might think that you can just not create a recovery.conf
file in that case, or create a dummy recovery.conf file with
restore_command='/bin/false'. However, then the system will not find the
existing timeline history files in the archive, and can pick a TLI
that's already in use. I found this out the hard way, and actually ended
up writing a restore_command that restore timeline history files
normally, but returns non-zero for any real other files; it wasn't pretty.
Another case is that you take a backup from a standby server; you can't
write a restore-point WAL record in a standby.
If we want to avoid adding a new option for this, how about a magic
restore point called "consistent" or "immediate":
recovery_target_name='immediate'
That would stop recovery right after reaching consistency, but there
wouldn't be an actual restore point record in the WAL stream.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
