Re: replication slot restart_lsn initialization

On Fri, Aug 14, 2015 at 9:54 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-08-14 16:44:44 +0900, Michael Paquier wrote:
> > Commit 6fcd8851, which is the result of this thread, is not touching
> > the replication protocol at all. This looks like an oversight to me:
> > we should be a maximum consistent between the SQL interface and the
> > replication protocol if possible, and it looks useful to me to be able
> > to set restart_lsn when creating the slot as well when using a
> > replication connection.
>
> It wasn't, at least not from my side. You can relatively easily do
> nearly the same just by connecting to the slot and sending a feedback
> message. The complaint upthread (and/or a related thread) was that it's
> not possible to do the same from SQL.
>
> It'd be a good additional to offer the same facility to the replication
> protocol.
>
> > For now we can do that: CREATE_REPLICATION_SLOT IDENT K_PHYSICAL We
> > could append a keyword like RESERVE on this query. Or go through more
> > fancy things like (slot_options) where slot_options is a list of
> > option items, reserve = on/off. Thoughts? -- Michael
>
> I'd name it RESERVE_WAL. My feeling is that the options for the logical
> case are geared towards the output plugin, not the walsender. I think
> it'd be confusing to use (slot_options) differently for physical slots.
>

Yes, but the options list you pass to START_REPLICATION ... LOGICAL, not to
CREATE_REPLICATION_SLOT.

2c
--
Alex