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.
Greetings,
Andres Freund