Re: Copy function for logical replication slots - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Copy function for logical replication slots
Date
Msg-id CAMsr+YF0NOxsRr2PDMu0kg_4n00iKkj8BdpWgd0z7jf2O=7xNw@mail.gmail.com
Whole thread Raw
In response to Copy function for logical replication slots  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On 28 June 2018 at 10:51, Masahiko Sawada <sawada.mshk@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

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: pgsql: Clarify use of temporary tables within partition trees
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: shared-memory based stats collector