Re: Standby trying "restore_command" before local WAL
| От | Stephen Frost |
|---|---|
| Тема | Re: Standby trying "restore_command" before local WAL |
| Дата | |
| Msg-id | 20180808161551.GL27724@tamriel.snowman.net обсуждение исходный текст |
| Ответ на | Re: Standby trying "restore_command" before local WAL (David Steele <david@pgmasters.net>) |
| Список | pgsql-hackers |
Greetings, * David Steele (david@pgmasters.net) wrote: > I can see cases where it *might* be worth it, but several backup tools > support prefetch and/or parallelism which should be able to keep > Postgres fed with WAL unless there is very high latency to the repo. > I'm not sure the small performance boost (if any) would be enough to > justify the extra code paths and tests. ... > That said, if there is anything we can do in core to make these tools > simpler or more performant I'm all for it. For instance, it might be > good to have return code (as suggested upstream) that indicates to > Postgres that the segment in pg_wal is a good choice. Some use cases > might benefit enormously even if it doesn't make sense as a general case. Well, if there are some use cases that would benefit greatly from it then it may just be worth it. That said, it doesn't sound like a common enough ask to be something we'd prioritize for pgbackrest, at least not without actual client demand/interest in it. If someone else wants to write the tests and the code and contribute that capability, we'd certainly welcome it. Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления: