Re: Minimal logical decoding on standbys
От | Alvaro Herrera |
---|---|
Тема | Re: Minimal logical decoding on standbys |
Дата | |
Msg-id | 20190611183650.GA25310@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Minimal logical decoding on standbys (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Minimal logical decoding on standbys
|
Список | pgsql-hackers |
On 2019-May-23, Andres Freund wrote: > On 2019-05-23 09:37:50 -0400, Robert Haas wrote: > > On Thu, May 23, 2019 at 9:30 AM Sergei Kornilov <sk@zsrv.org> wrote: > > > > wal_level is PGC_POSTMASTER. > > > > > > But primary can be restarted without restart on standby. We require wal_level replica or highter (currently only logical)on standby. So online change from logical to replica wal_level is possible on standby's controlfile. > > > > That's true, but Amit's scenario involved a change in wal_level during > > the execution of pg_create_logical_replication_slot(), which I think > > can't happen. > > I don't see why not - we're talking about the wal_level in the WAL > stream, not the setting on the standby. And that can change during the > execution of pg_create_logical_replication_slot(), if a PARAMTER_CHANGE > record is replayed. I don't think it's actually a problem, as I > outlined in my response to Amit, though. I don't know if this is directly relevant, but in commit_ts.c we go to great lengths to ensure that things continue to work across restarts and changes of the GUC in the primary, by decoupling activation and deactivation of the module from start-time initialization. Maybe that idea is applicable for this too? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: