On 28 June 2018 at 10:51, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> Hi, > > I'd like to propose a copy function for logical replication slots. > Currently when we create a new logical replication slot it starts to > read WAL from an LSN of the current insert. This function copies a > existing logical replication slot while changing output plugin and > persistence. That is, the copied new replication slot starts from the > same LSN as the source one. Since a new copied slot starts from the > same LSN of existing one we don't need to care about WAL reservation. > Strong agreement from me. The inability to switch plugins is a massive pain. I've worked around it with similar functions bundled into the extensions I work with that do logical decoding related work. It makes sense to have it in core. A use case I imagined is for investigations for example. I mean that > when replication collision occurs on subscriber there is no way to see > what replicated data is conflicting (perhaps error log helps it but is > not detailed) and there is no way to advance a replication origin in > order to exactly skip to apply conflicting data. pglogical handles this by letting you peek the slot in a separate json protocol output mode, but that doesn't help with pgoutput. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
