Re: Online enabling of checksums
От | Andres Freund |
---|---|
Тема | Re: Online enabling of checksums |
Дата | |
Msg-id | 20180801180640.w2tux7te3dje5qdf@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Online enabling of checksums (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: Online enabling of checksums
|
Список | pgsql-hackers |
Hi, On 2018-08-01 21:03:22 +0300, Sergei Kornilov wrote: > > They fail over to a secondary to do maintenance on a primary. > But this is not problem even in current patch state. We can restart replica before failover and it works. I tested thisbehavior during my review. > We can: > - call pg_enable_data_checksums() on master > - wait change data_checksums to inprogress on replica That's *precisely* the problem. What if your replicas are delayed (e.g. recovery_min_apply_delay)? How would you schedule that restart properly? What if you later need to do PITR? > - restart replica - we can restart replica before promote, right? > - promote this replica > - checksum helper is launched now and working on this promoted cluster This doesn't test the consequences of the restart being skipped, nor does it review on a code level the correctness. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: