Re: Remove Deprecated Exclusive Backup Mode

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 &amp;&amp; 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

In response to

Responses

Browse pgsql-hackers by date

  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