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