From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Rename backup_label to recovery_control |
Date: | 2023-10-18 14:31:26 |
Message-ID: | e87280a7-1b6c-31bf-bc6b-70d06a336484@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/18/23 03:07, Peter Eisentraut wrote:
> On 16.10.23 17:15, David Steele wrote:
>>> I also do wonder with recovery_control is really a better name. Maybe
>>> I just have backup_label too firmly stuck in my head, but is what that
>>> file does really best described as recovery control? I'm not so sure
>>> about that.
>>
>> The thing it does that describes it as "recovery control" in my view
>> is that it contains the LSN where Postgres must start recovery (plus
>> TLI, backup method, etc.). There is some other informational stuff in
>> there, but the important fields are all about ensuring consistent
>> recovery.
>>
>> At the end of the day the entire point of backup *is* recovery and
>> users will interact with this file primarily in recovery scenarios.
>
> Maybe "restore" is better than "recovery", since recovery also happens
> separate from backups, but restoring is something you do with a backup
> (and there is also restore_command etc.).
I would not object to restore (there is restore_command) but I do think
of what PostgreSQL does as "recovery" as opposed to "restore", which
comes before the recovery. Recovery is used a lot in the docs and there
is also recovery.signal.
But based on the discussion in [1] I think we might be able to do away
with backup_label entirely, which would make this change moot.
Regards,
-David
[1]
https://www.postgresql.org/message-id/0f948866-7caf-0759-d53c-93c3e266ec3f%40pgmasters.net
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2023-10-18 14:38:39 | Re: The danger of deleting backup_label |
Previous Message | Tomas Vondra | 2023-10-18 14:29:47 | Re: BRIN minmax multi - incorrect distance for infinite timestamp/date |