Re: replay pause vs. standby promotion
От | Sergei Kornilov |
---|---|
Тема | Re: replay pause vs. standby promotion |
Дата | |
Msg-id | 19108601585229516@iva1-3b1c0a1a240c.qloud-c.yandex.net обсуждение исходный текст |
Ответ на | Re: replay pause vs. standby promotion (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Список | pgsql-hackers |
Hello > If we don't ignore walreceiver and does try to connect to the master, > a promotion and recovery cannot end forever since new WAL data can > be streamed. You think this behavior is more consistent? We have no simple point to stop replay. Well, except for "immediately" - just one easy stop. But I agree that this is not the best option. Simple and clear, butnot best one for data when we want to replay as much as possible from archive. > IMO it's valid to replay all the WAL data available to avoid data loss > before a promotion completes. But in case of still working primary (with archive_command) we choose quite random time to promote. A random time when theprimary did not save the new wal segment. or even when a temporary error of restore_command occurs? We mention just cp command in docs. I know users uses cp (e.g.from NFS) without further error handling. regards, Sergei
В списке pgsql-hackers по дате отправления: