On Wed, Apr 28, 2010 at 7:22 AM, Simon Riggs <simon@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 <simon@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.linnakangas@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