Re: pg_basebackup, manifests and backends older than ~12
От | David Steele |
---|---|
Тема | Re: pg_basebackup, manifests and backends older than ~12 |
Дата | |
Msg-id | e984fed9-3d16-d5d8-5e03-27de88ceab68@pgmasters.net обсуждение исходный текст |
Ответ на | Re: pg_basebackup, manifests and backends older than ~12 (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_basebackup, manifests and backends older than ~12
|
Список | pgsql-hackers |
On 4/10/20 4:41 PM, Stephen Frost wrote: > Greetings, > > * David Steele (david@pgmasters.net) wrote: >> On 4/10/20 4:09 AM, Michael Paquier wrote: >>> I have noticed that attempting to use pg_basebackup from HEAD leads to >>> failures when using it with backend versions from 12 and older: >>> $ pg_basebackup -D hoge >>> pg_basebackup: error: backup manifests are not supported by server >>> version 12beta2 >>> pg_basebackup: removing data directory "hoge" >>> >>> This is a bit backwards with what we did in the past to maintain >>> compatibility silently when possible, for example look at the handling >>> of temporary replication slots. Instead of an error when means to >>> force users to have to specify --no-manifest in this case, shouldn't >>> we silently disable the generation of the backup manifest? We know >>> that this option won't work on older server versions anyway. >> >> I'm a bit conflicted here. I see where you are coming from, but given that >> writing a manifest is now the default I'm not sure silently skipping it is >> ideal. > > It's only the default in v13.. Surely when we connect to a v12 or > earlier system we should just keep working and accept that we don't get > a manifest as part of that. Yeah, OK. It's certainly better than forcing the user to disable manifests, which might also disable them for v13 clusters. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: