Re: Rename backup_label to recovery_control
От | David Steele |
---|---|
Тема | Re: Rename backup_label to recovery_control |
Дата | |
Msg-id | e87280a7-1b6c-31bf-bc6b-70d06a336484@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Rename backup_label to recovery_control (Peter Eisentraut <peter@eisentraut.org>) |
Список | 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
В списке pgsql-hackers по дате отправления: