Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Date
Msg-id 621E6C2E.2050801@anastigmatix.net
Whole thread Raw
In response to Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  (David Steele <david@pgmasters.net>)
Responses Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
List pgsql-hackers
On 03/01/22 13:22, David Steele wrote:
> I think people are going to complain no matter what. If scripts are being
> maintained changing the name is not a big deal (though moving from exclusive
> to non-exclusive may be). If they aren't being maintained then they'll just
> blow up a few versions down the road when we remove the compatibility
> functions.

I might have already said enough in the message that crossed with this,
but I think what I'm saying is there's a less-binary distinction between
scripts that are/aren't "being maintained".

There can't really be many teams out there thinking "we'll just ignore
these scripts forever, and nothing bad will happen." They all know they'll
have to do stuff sometimes. But it matters how we allow them to schedule it.

In the on-ramp, at first there was only exclusive. Then there were both
modes, with exclusive being deprecated, so teams knew they'd need to do
stuff, and most by now probably have. They were able to do separation of
hazards and schedule that work; they did not have to pile it onto the
whole plate of "upgrade PG from 9.5 to 9.6 and make sure everything works".

So now we're dropping the other shoe: first there was one mode, then both,
now there's only the other one. Again there's some work for teams to do;
let's again allow them to separate hazards and schedule that work apart
from the whole 14 to 15 upgrade project.

We can't help getting complaints in the off-ramp from anybody who ignored
the on-ramp. But we can avoid clobbering the teams who dutifully played
along before, and only want the same space to do so now.

Regards,
-Chap



pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Implementing Incremental View Maintenance
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers