Re: Minimal logical decoding on standbys
Andres Freund <andres@anarazel.de>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reduce the log level in 035_standby_logical_decoding.pl.
- 3034dc56ef4b 16.0 landed
-
035_standby_logical_decoding: Add missing waits for replication
- 57411c82ce86 16.0 landed
-
For cascading replication, wake physical and logical walsenders separately
- e101dfac3a53 16.0 landed
-
Handle logical slot conflicts on standby
- 26669757b6a7 16.0 landed
-
Support invalidating replication slots due to horizon and wal_level
- be87200efd93 16.0 landed
-
Prevent use of invalidated logical slot in CreateDecodingContext()
- 4397abd0a2af 16.0 landed
-
Replace replication slot's invalidated_at LSN with an enum
- 15f8203a5975 16.0 landed
-
Pass down table relation into more index relation functions
- 61b313e47eb9 16.0 landed
-
Assert only valid flag bits are passed to visibilitymap_set()
- a88a18b1250b 16.0 landed
-
Remove unused _bt_delitems_delete() argument.
- dc43492e46c7 14.0 cited
-
Add xl_btree_delete optimization.
- d2e5e20e5711 13.0 cited
Hi, 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. Greetings, Andres Freund