Re: Rename backup_label to recovery_control - Mailing list pgsql-hackers

On 10/16/23 10:19, Robert Haas wrote:
> On Sat, Oct 14, 2023 at 2:22 PM David Steele <david@pgmasters.net> wrote:
>> I was recently discussing the complexities of dealing with pg_control
>> and backup_label with some hackers at PGConf NYC, when David Christensen
>> commented that backup_label was not a very good name since it gives the
>> impression of being informational and therefore something the user can
>> delete. In fact, we see this happen quite a lot, and there have been
>> some other discussions about it recently, see [1] and [2]. I bounced the
>> idea of a rename off various hackers at the conference and in general
>> people seemed to think it was a good idea.
> 
> Personally, I feel like this is an area where we keep moving the parts
> around but I'm not sure we're really getting to anything better. We
> got rid of recovery.conf. 

I agree that this was not an improvement. I was fine with bringing the 
recovery options into the GUC fold but never really liked forcing them 
into postgresql.auto.conf. But I lost that argument.

> We got rid of exclusive backup mode. We
> replaced pg_start_backup with pg_backup_start. 

I do think this was an improvement. For example it allows us to do [1], 
which I believe is a better overall solution to the problem of torn 
reads of pg_control. With exclusive backup we would not have this option.

> It feels like every
> other release or so we whack something around here, but I'm not
> convinced that any of it is really making much of an impact. If
> there's been any decrease in people screwing up their backups, I
> haven't noticed it.

It's pretty subjective, but I feel much the same way. However, I think 
the *areas* that people are messing up are changing as we remove 
obstacles and I feel like we should address them. backup_label has 
always been a bit of a problem -- basically deciding should it be deleted?

With the removal of exclusive backup we removed the only valid use case 
(I think) for removing backup_label manually. Now, it should probably 
never be removed manually, so we need to make adjustments to make that 
clearer to the user, also see [1].

Better messaging may also help, and I am also thinking about that.

> To be fair, I will grant that renaming pg_clog to pg_xact_status and
> pg_xlog to pg_wal does seem to have reduced the incidence of people
> nuking those directories, at least IME. So maybe this change would
> help too, for similar reasons. But I'm still concerned that we're
> doing too much superficial tinkering in this area. Breaking
> compatibility is not without cost.

True enough, but ISTM that we have gotten few (or any) actual complaints 
outside of hackers speculating that there will be complaints. For the 
various maintainers of backup software this is just business as usual. 
The changes to pg_basebackup are also pretty trivial.

> 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.

Regards,
-David

---

[1] 
https://www.postgresql.org/message-id/1330cb48-4e47-03ca-f2fb-b144b49514d8%40pgmasters.net