Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file
Дата
Msg-id 621E6C2E.2050801@anastigmatix.net
обсуждение исходный текст
Ответ на Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  (David Steele <david@pgmasters.net>)
Ответы Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Yugo NAGATA
Дата:
Сообщение: Re: Implementing Incremental View Maintenance
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Expose port->authn_id to extensions and triggers