Re: Change pgarch_readyXlog() to return .history files first
Вложения
В списке pgsql-hackers по дате отправления:
| От | David Steele |
|---|---|
| Тема | Re: Change pgarch_readyXlog() to return .history files first |
| Дата | |
| Msg-id | 43343793-7e7b-f9d4-be3e-283f19b90e87@pgmasters.net обсуждение исходный текст |
| Ответ на | Change pgarch_readyXlog() to return .history files first (David Steele <david@pgmasters.net>) |
| Список | pgsql-hackers |
On 12/13/18 11:53 AM, David Steele wrote: > Hackers, > > The alphabetical ordering of pgarch_readyXlog() means that on promotion > 000000010000000100000001.partial will be archived before 00000002.history. > > This appears harmless, but the .history files are what other potential > primaries use to decide what timeline they should pick. The additional > latency of compressing/transferring the much larger partial file means > that archiving of the .history file is delayed and greatly increases the > chance that another primary will promote to the same timeline. > > Teach pgarch_readyXlog() to return .history files first (and in order) > to reduce the window where this can happen. This won't prevent all > conflicts, but it is a simple change and should greatly reduce > real-world occurrences. > > I also think we should consider back-patching this change. It's hard to > imagine that archive commands would have trouble with this reordering > and the current ordering causes real pain in HA clusters. Some gcc versions wanted more parens, so updated in attached. -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера