From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Remove Deprecated Exclusive Backup Mode |
Date: | 2018-12-13 19:29:04 |
Message-ID: | 18ce3d25-dc3c-278a-8a13-167dcf43fd5e@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/13/18 2:00 PM, Peter Eisentraut wrote:
> On 11/12/2018 23:24, David Steele wrote:
>> @@ -845,7 +838,7 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
>> rights to run pg_start_backup (superuser, or a user who has been granted
>> EXECUTE on the function) and issue the command:
>> <programlisting>
>> -SELECT pg_start_backup('label', false, false);
>> +SELECT pg_start_backup('label', false);
>> </programlisting>
>> where <literal>label</literal> is any string you want to use to uniquely
>> identify this backup operation. The connection
>
> Is it good to change the meaning of an existing interface like that?
Good question.
We could leave the third parameter (changing the default to false) and
error if it has any value but false. It's a bit ugly but it does
maintain compatibility with the current non-exclusive backup interface.
And, the third parameter would never need to be specified unless we add
a fourth.
Or we could add a new function and deprecate this one -- but what to
call it?
I agree it's not very cool to break code for users who actually *did*
migrate to non-exclusive backups.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-12-13 19:40:21 | Re: Reorganize collation lookup time and place |
Previous Message | Tom Lane | 2018-12-13 19:23:40 | Re: Upgrading pg_statistic to handle collation honestly |