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-06-04 15:51:01 +0530, Amit Khandekar wrote: > After giving more thought on this, I think it might make sense to > arrange for the xl_running_xact record to be sent from master to the > standby, when a logical slot is to be created on standby. How about > standby sending a new message type to the master, requesting for > xl_running_xact record ? Then on master, ProcessStandbyMessage() will > process this new message type and call LogStandbySnapshot(). I think that should be a secondary feature. You don't necessarily know the upstream master, as the setup could be cascading one. I think for now just having to wait, perhaps with a comment to manually start a checkpoint, ought to suffice? Greetings, Andres Freund