Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary
От | Nathan Bossart |
---|---|
Тема | Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary |
Дата | |
Msg-id | aMog06qbmvLLcFSw@nathan обсуждение исходный текст |
Ответ на | Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary
|
Список | pgsql-bugs |
On Tue, Sep 16, 2025 at 04:42:39PM -0700, Masahiko Sawada wrote: > On Tue, Sep 16, 2025 at 3:52 PM Nazneen Jafri <jafrinazneen@gmail.com> wrote: >> The parameter max_active_replication_origins should be added to the list >> of mandatory settings that must match between primary and replica during >> creation >> >> [...] > > Thank you for the report! > > As reported, the standby could not continue the recovery (especially > replaying XLOG_REPLORIGIN_ records) if its > max_active_replication_origins is less than the primary's setting. One > idea to fix this issue is to require for standbys to have at least the > same max_active_replication_origins value as the primary as we do for > other GUC parameters such as max_worker_processes and max_wal_senders. > It needs to add max_active_replication_origins to the control file and > bumps the PG_CONTROL_VERSION. Given that we've released 18RC1 and > probably are close to 18 release, I'd like to hear opinions whether > such a fix is acceptable or not. I haven't tried reproducing it on older versions (with max_replication_slots instead of max_active_replication_origins), but after looking at the code for a bit, I'm growing skeptical that this is new to v18. In any case, the PANIC provides a clear error message, which is roughly the same as what we'd say with the control file approach, right? -- nathan
В списке pgsql-bugs по дате отправления: