| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net>, 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 07:07:38 |
| Message-ID: | a4c77926-e6ff-403c-a0f5-664ebc9e8437@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2023-10-18 07:20:55 | Re: run pgindent on a regular basis / scripted manner |
| Previous Message | torikoshia | 2023-10-18 06:50:39 | Re: pg_rewind WAL segments deletion pitfall |