On Fri, Aug 14, 2015 at 9:54 AM, Andres Freund <and...@anarazel.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
