On Wed, Apr 28, 2010 at 7:22 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Wed, 2010-04-28 at 06:56 -0400, Robert Haas wrote: >> On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> > On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote: >> >> On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas >> >> <heikki.linnakan...@enterprisedb.com> wrote: >> >> > This doesn't contain any changes to pg_start_backup() yet, that's a >> >> > separate issue and still under discussion. >> >> >> >> I'm thinking of changing pg_start_backup and pg_stop_backup so that >> >> they just check that wal_level >= 'archive', and changing pg_stop_backup >> >> so that it doesn't wait for archiving when archive_mode is OFF. >> >> >> >> This change is very simple and enables us to take a base backup for SR >> >> even if archive_mode is OFF. Thought? >> > >> > Makes sense. >> > >> > I'm wondering whether this could cause problems with people taking hot >> > backups that aren't aimed at SR. Perhaps we could have 2 new functions >> > whose names are more closely linked to the exact purpose: >> > pg_start_replication_copy() etc.. >> > which then act exactly as you suggest. >> >> Hmm. That seems a bit complicated. Why can't we just let people use >> the existing functions the way they always have? > > We can, but I already gave a reason why we should not. > > IIRC it was you that suggested changing the names of things if the > behaviour changes.
Absolutely, but I'm arguing that we shouldn't change the behavior in the first place. At least as I understand it, even when not using archive_mode, streaming replication, or hot standby, it's still perfectly legal to use pg_start_backup() to take a hot backup. I don't see why we would either (a) break that use case or (b) create another function that does the same thing but with one extra error check. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers